A webhook endpoint can return successful responses while its background work falls behind. If monitoring checks only HTTP status, the integration may look healthy even though the application is showing old data.
Track the handover from accepted event to completed work. The age of the oldest unfinished item is often more useful than a queue count alone.
Read several signals together
A queue of ten items may be normal during a short burst. A single item stuck for six hours can be more serious. Record pending count, oldest age, processing duration, retry count, and items requiring manual attention.
Separate temporary retries from permanent validation failures. One malformed event should not repeatedly block every later item. At the same time, moving it aside should leave a clear record for investigation.
Use safe event IDs and categories in diagnostics. Avoid putting full listener payloads into alerts that reach many people.
Build an actionable alert
Write what the team should check when a threshold is crossed: worker availability, storage errors, provider rate limits, a recent deployment, or a known poison event. An alert that says only “queue large” creates work without a useful starting point.
Test by pausing a controlled worker while continuing to accept fixture events. Confirm that the age signal grows, the alert appears as intended, and processing resumes after the worker returns.
Choose thresholds from your product's freshness expectations and observed behavior. Do not invent a universal queue size for every podcast app. The purpose is to identify a delay that matters to listeners, not to keep every operational chart at zero.