ESP API latency tracked
Why it matters
ESP API latency is a leading indicator of outages and rate-limit throttling. A call that normally completes in 80 ms suddenly taking 4 seconds means the ESP is struggling — but without per-call timing recorded to a metrics system or log, the only way you discover the degradation is through user reports or queue backlog growth. ISO 25010 performance-efficiency requires that time-behaviour is measurable. Missing timing on error paths is especially dangerous: slow errors are the most likely signal of an impending outage.
Severity rationale
Medium because latency spikes are invisible without instrumentation, delaying incident detection until the problem has already caused queue backlog or send failures.
Remediation
Wrap the ESP send call in your ESP adapter (e.g., src/lib/email/providers/sendgrid.ts) so both success and error paths record the duration:
const start = Date.now()
try {
await esp.send(message)
metrics.histogram('esp_send_duration_ms', Date.now() - start, { result: 'success' })
} catch (err) {
metrics.histogram('esp_send_duration_ms', Date.now() - start, { result: 'error' })
throw err
}
Every call site must record timing — partial instrumentation on success paths only will 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 · performance-efficiency.time-behaviour — Performance Efficiency / Time Behaviour — ESP latency must be measurable
Taxons
History
- 2026-04-18·v1.0.0·Initial import from operational-resilience-email·automated