Troubleshoot a Notifier and Delivery
Start from a missing receiver Delivery, Unverified or Paused state, failed Test Delivery, Retrying or Failing Delivery Health, or a receiver response.
Receiver failure can change Delivery Health, but it never changes Endpoint Availability or the Incident.
A receiver Delivery is missing
First confirm that Scheduled Check evidence opened an Incident or confirmed Recovery and created a Notification Event. Then inspect the Notifier as it existed at that moment: it must have been subscribed to that event and Monitor, Verified, and Enabled. Later subscription or lifecycle changes do not backfill an earlier Notification Event.
New Notifiers default to no events and no Monitors. Compare the saved choices with Configure a Notifier before investigating the receiver.
The Notifier is Unverified or Paused
An Unverified Notifier cannot receive production Notification Events. A Paused Notifier is not eligible for new events. A successful Test Delivery changes verification to Verified, but you must still choose Enable as a separate action.
Changing the Destination Type or target URL, or rotating a Generic signing secret, returns the Notifier to Unverified and Paused and cancels unfinished Deliveries for the old configuration.
A Test Delivery fails
Confirm that the saved target is an existing public HTTPS receiver with no embedded credentials and that the confirmed Destination Type matches it. Test Delivery sends a live diagnostic request and records safe evidence separately from production Delivery Health.
A failed Test Delivery does not verify a new Notifier. A later failed Test Delivery on an already Verified Notifier remains visible but does not revoke verification, pause an Enabled Notifier, or cancel production work. Review Verify and enable a Notifier for the complete state sequence.
Delivery Health is Retrying
Retrying means a production Delivery Attempt failed in a way PointWarden will try again. Network failures and receiver responses 408, 425, 429, and 500 through 599 are retryable. A 429 response may include a Retry-After value, which PointWarden limits to 24 hours.
A Delivery keeps one stable identity across retries. Make a Generic receiver idempotent so another Delivery Attempt does not process the same Notification Event twice.
Delivery Health is Failing
Failing means the latest production Delivery ended permanently after its retries or received a non-retryable response. Future subscribed Notification Events are still attempted; Failing does not disable the Notifier.
An invalid or no-longer-public target permanently fails only that Delivery. It does not create a Failing Check and cannot affect Endpoint Availability.
Read receiver responses safely
| Receiver evidence | Delivery outcome |
|---|---|
| 200 through 299 | The Delivery Attempt succeeds. |
| 408, 425, 429, or 500 through 599 | The response is retryable while attempts remain. |
| 300 through 399 | The redirect is rejected. PointWarden never follows Notifier redirects. |
| Other non-2xx responses | The Delivery fails permanently. |
Inspect Delivery evidence for the final status when available, sanitized failure category, duration, and attempt time.