The 38-second budget
Where every second between an event happening and a phone ringing actually goes — and the one delay we cannot fix because it belongs to your cloud provider.
We publish a median detect-to-page of 38 seconds. People assume it is a marketing number. It is a budget, it is allocated, and roughly a third of it is spent on something we do not control.
Here is the whole thing, for a control-plane detection on AWS, measured at p50 across customers in the last full quarter.
The ledger
| Stage | p50 | p99 | Whose fault |
|---|---|---|---|
| Event occurs → visible to us | 11.4 s | 4 m 50 s | AWS (CloudTrail delivery) |
| Fetch → normalise to OCSF | 4.1 s | 9.2 s | ours |
| Enrichment (identity, asset, IAM reach) | 2.8 s | 7.4 s | ours |
| Correlation window evaluation | 9.6 s | 22 s | ours, deliberately |
| Situation open → notify dispatched | 1.9 s | 4.1 s | ours |
| Dispatch → phone rings | 8.2 s | 31 s | PagerDuty / Slack / Opsgenie |
| Total | 38.0 s | 6 m 04 s |
Two rows deserve explanation and one deserves an apology.
The correlation window is deliberate
Nine and a half seconds sitting in a window looks like waste. It is the opposite: it is the entire product.
A correlation pattern needs to see whether the other conditions arrive. If we evaluate the instant the first signal lands, we either alert on a single event — which is the thing we spent two years arguing against — or we alert and then retract. So patterns hold a window, typically 10 seconds for high-signal combinations and up to 15 minutes for slow ones like privilege escalation chains.
The window is not dead time. Partial matches are already visible in the console, flagged as forming, from the moment the first condition lands. A customer watching the live view sees a situation assembling before it pages. Several of our most engaged teams treat forming as the real interface and the page as a backstop.
The row we cannot fix
CloudTrail management events are delivered on AWS’s schedule. AWS documents “typically within 15 minutes”; in practice we observe a p50 of 11.4 seconds and a p99 of just under five minutes, and the tail is not under anyone’s control but theirs.
This is the honest ceiling on cloud control-plane detection, and every vendor has it. If someone quotes you a sub-second detect-to-page on a CloudTrail-sourced detection, they are either measuring from the moment the event reached their system — a measurement that conveniently excludes the slowest stage — or they are not using CloudTrail.
Three things reduce the exposure, and we do all three:
- EventBridge for the events that support it. A subset of control-plane activity is available via EventBridge with single-digit-second latency. We subscribe to it and reconcile against CloudTrail later for completeness, preferring whichever arrives first.
- Runtime sensors do not wait. Anything the eBPF sensor sees — process execution, connections, egress volume — reaches us in under a second, because it is our pipe. A detection that can be expressed at runtime rather than at the control plane should be.
- We show you the delivery lag. Every situation displays event-occurred and event-received timestamps separately. If you were paged four minutes after the fact, you can see exactly where those minutes went, and that it was not us.
Where our next second comes from
Enrichment, at 2.8 s p50, is the stage we are working on. Most of it is IAM reach computation — walking the policy graph to answer “what could this principal touch” — which we currently do on demand. Precomputing reach per principal on policy change, rather than per situation, should take that row under a second. It is a cache-invalidation problem and therefore taking longer than planned.
The dispatch row we will not chase. Eight seconds to make a phone ring is a notification-provider problem, and a second shaved there is not worth an integration we maintain ourselves.