WarnFireDocs

Delivery evidence

Review Delivery Activity

Filter notification attempts, distinguish provider handoff from verified delivery, and trace failures to an incident and responder.

Version 1.0 Status Needs verification For Tenant ownersFor Tenant administratorsFor Responders deliverytroubleshootingnotificationsevidence

Delivery Activity shows the last 30 days of workspace notification attempts. It distinguishes a request, provider acceptance, verified delivery, device receipt or opening, and a terminal failure.

Before you begin

You need console access to the workspace. For a controlled check, first run a test incident and note its incident name and responder.

Find a delivery attempt

  1. Open Delivery Activity from the main navigation.
  2. Review the summary counts for Requested, Provider accepted, Verified delivered, Failed, and Pending.
  3. Set Channel to push, email, SMS, or voice when investigating one path.
  4. Set Outcome to requested, accepted, delivered, opened, or failed.
  5. Use Search to match an incident name, responder, or failure code.
  6. Read the matching row from left to right:
    • when WarnFire requested the page;
    • the incident and responder;
    • the channel, and the provider name for SMS rows;
    • the current outcome and any failure code;
    • the strongest evidence time and provider status; and
    • whether the attempt was free or consumed SMS or voice credits.

The table excludes full destinations, message bodies, provider identifiers, callback payloads, and internal route pricing.

Interpret the result

  • Requested means WarnFire created the attempt; it does not prove provider handoff.
  • Accepted means the provider accepted responsibility; it does not prove that a device, inbox, or person received the page.
  • Delivered means a terminal provider callback or authenticated device receipt supplied stronger evidence.
  • Opened means the authenticated mobile app reported that the notification was opened for its incident target.
  • Failed is a terminal non-delivery outcome. Use the failure code and incident activity to determine the corrective action.
  • Pending is a summary count, not a row outcome or filter. It includes attempts that do not yet have terminal delivery evidence, including some provider-accepted attempts. A pending attempt is not automatically a failure.

Read Delivery evidence for the strongest result each channel can supply and the limits of that evidence.

Verify it worked

For a test incident, confirm that at least one row matches the incident and expected responder. Compare its channel and outcome with what the responder observed. For push, verify device-specific received or opened evidence when the app reported it; do not promote provider acceptance to delivery.

If no row appears, reset all filters to All, search with a shorter incident name, and wait up to 30 seconds for the automatic refresh. Then use the paging troubleshooting checklist if the expected attempt is still absent.

Next steps