Probes: Actively Verify What Must Work

Probes are Panaptico’s active verification mechanism. While System Sensors read state from APIs and streams, Probes attempt the thing that must actually work: the restore completes, the failover triggers, the sign-in path succeeds. Probes are explicitly enabled, scoped to specific entities or paths, and fully evidenced. If a Probe does not run or does not return proof, that absence is itself an alarm.

​

How Probes work

You define a Probe by specifying:

• What to test — a behavior, path, or negative condition
• Where to test it — the target entity, network segment, or service
• When to test — schedule or trigger conditions
• What success looks like — the expected result or absence of a result

Panaptico executes the Probe, records the outcome, and stores the evidence. The result feeds into Signals, Initiatives, and Routing just like any other verification result.

​

Types of Probes

• Functional Probes — verify that a capability works: restore a database from backup, fail over to a secondary region, complete an end-to-end sign-in flow
• Negative Verification — prove that something cannot happen: send a packet to a blocked port and confirm it is dropped, attempt access with revoked credentials and confirm denial
• Path Probes — trace a dependency chain: verify that a user can reach an application through the intended network path with the expected controls applied at each hop

​

Example: Negative verification

You have a network segmentation policy that prohibits direct access from the development VPC to the production database subnet. You define a Probe that sends a connection request from a development instance to the production database port. The expected result is a timeout or explicit rejection. If the connection succeeds, the Probe returns off target and Panaptico surfaces the gap in the relevant Initiative. If the Probe fails to run, the result is unknown, not assumed safe.

​

When to use Probes

Use Probes when reading state is not enough and you need proof that behavior matches intent. They are essential for recovery verification, security control validation, and any Initiative where missing proof is unacceptable.