Marketplace Delivery Error Alerting with 429-Aware Metrics API Polling

When assessing error alerting using metrics poll data, consider each poll as an independent, repeatable read. View HTTP 429 responses as inconclusive indications rather than proof of correct or incorrect notification delivery. Always save the checkpoint after the last successful window, obey any Retry-After headers, and incorporate randomized, bounded jittered backoff between attempts.

Alert only when a failure is confirmed after a complete window has elapsed. For a marketplace service, this distinction avoids two potential pitfalls: a poller might clear a genuine delivery error thinking no failures occurred due to throttling, or it may send unnecessary alerts solely because the monitoring system was rate-limited.

The fundamental principle is that "missing is not zero." To establish reliable error alerting from metrics API polls, adhere to four key principles: treat each window independently even after retries, disregard 429 responses when calculating checkpoint progress, disregard partial metric pages as completed windows, and only update alert states when observations are firmly tied to a closed window and successful data retrieval.

These principles are more critical than the scheduling mechanism. Implement locked polling windows with unique identities like "2026-09-27T10:14:00Z/60s" to ensure retries reuse the same checkpoint. Clearly distinguish failure types: transport errors (unknown), HTTP 429 (rate limiting), parse errors (untrustworthy data), and checkpoint failures (replayable).

Keep failure counters simple by using bounded dimensions such as channel, failure class, and deployment region instead of high-cardinality elements like order IDs or URLs. Design the architecture around a checkpointed pull worker with a state machine that separates delivery failures from poll health, only retries unfinished observations, and provides a freshness signal to avoid treating stale data as current health.