Capacity alerts at 80% threshold
Why it matters
Capacity alerts at failure (queue full, ESP quota exceeded) give operators zero time to react — sends are already failing when the alert fires. An 80% threshold alert gives operators time to scale workers, contact the ESP about a quota increase, or delay a non-urgent campaign before the limit is hit. ISO 25010 reliability.operability requires that the system communicates approaching resource exhaustion, not just completed resource exhaustion. The Monitoring & Alerting category checks in this bundle verify that signals are being measured — this check verifies that pre-warning thresholds are configured on those signals.
Severity rationale
Low because the gap between no pre-warning and pre-warning alerts is operational comfort rather than correctness — sends degrade at 100% regardless, but operators with early warning can prevent reaching 100%.
Remediation
Add a threshold check in the queue monitoring poller for at least one capacity metric — daily send quota is the most common:
const DAILY_QUOTA = 100_000
const sentToday = await countSentToday()
if (sentToday > DAILY_QUOTA * 0.8) {
await alertOps(
`Daily send quota at ${Math.round(sentToday / DAILY_QUOTA * 100)}% — ${DAILY_QUOTA - sentToday} sends remaining`,
'warning'
)
}
The threshold value must be explicitly defined in code or configuration — a magic number with no comment explaining it is the limit does not satisfy this check.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Operational Resilience (Email) Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · reliability.operability — Reliability / Operability — pre-warning at 80% threshold enables proactive capacity management
Taxons
History
- 2026-04-18·v1.0.0·Initial import from operational-resilience-email·automated