Escalation criteria
Deciding severity while an incident is running is how inconsistent decisions get made. The criteria below are fixed in advance, and every figure on this page is read directly from the constant the running system enforces – so the procedure cannot quietly drift away from the implementation.
Service is impaired and the impairment is measurable. Automatic remediation runs; the event is recorded whether or not anyone is watching.
Triggers: worker failure rate, latency or queue depth past the thresholds below; heartbeat stale; database unreachable.
Something has moved outside its normal range but service is intact. Recorded and observed rather than acted on – most of these resolve without intervention.
Triggers: activity beyond 2σ from the hourly baseline; disk below the degraded threshold; a source approaching the ban count.
Expected activity on an internet-facing host. Scans, probes and blocked sources are filed for the record and for the baseline, and are not events in themselves.
A quiet watch is still reported. "Nothing happened" is a finding.
| Condition | Threshold | Response |
|---|---|---|
| Packet failure rate | 5.0% | Anomaly recorded against the incident |
| Mean processing latency | 40ms | Health check reports degraded |
| Queue depth | 40 | Queue growth recorded; consumer is behind the producer |
| Worker heartbeat age | 15s | Worker treated as stalled – the failure that produces no error |
| Fault window before auto-remediation | 45s | Fault cleared, worker queue reset, recovery verified by measurement |
| Cooldown between incidents | 2 min | Applies globally, so no combination of sources can pin the system degraded |
| Disk free – degraded / unhealthy | 20% / 10% | Reported by the health check |
| Detail retention | 30 days | Detail rows pruned; aggregate counts retained |
| Detection coalescing window | withheld | Repeat detections from one source counted, then summarised once |
| Requests before a source is blocked | withheld | Blocked at the firewall by the intrusion filter |
| Block duration | withheld | Long enough to be a cost, short enough that a shared address is not punished |
| Public feed delay | withheld | Denies a live readout of which requests trip a filter |
| Fault trigger rate limit | 1 / 10 min | Per source, on the only mutation endpoint that exists |
The worker thresholds above are published because that subsystem exists to be demonstrated – knowing exactly what trips it costs nothing. The security values are a different matter. Publishing the number of requests that earns a block, how long it lasts, and how long the feed is delayed hands anyone probing this host the precise recipe for staying underneath all three.
Delaying the public feed and then printing the thresholds on another page would make the delay pointless. So the reasoning and the categories are published and the trip values are not – which is the same judgement anyone running a monitored system has to make about how much of their own detection to describe in public.
Thresholds are a floor, not the whole method. A fixed number only catches what somebody thought to configure, which is why edge activity is also measured against a rolling baseline – an hour can be well inside every threshold on this page and still be wrong for this system at this time of day.