The event exists but nobody got the alert: a delivery checklist

By Gate & Shift Editorial Desk · Planned week of 2026-12-21 · Documentation reviewed 2026-11-15

The event is in the application at 01:42. The duty phone stayed quiet. That is a different fault from a camera failing to detect an event, and it needs its own trail of timestamps.

Use this proposed checklist alongside the supplier's actual documentation. Delivery logs, retry behavior, signing rules and supported channels all vary, so nothing here assumes every product exposes them.

Save the starting evidence

Keep the event identifier, camera, rule version and creation time. Note the timezone and where each clock comes from. If a screenshot is permitted, include enough context to identify the event without copying more footage or personal information than the investigation needs.

Then name the expected endpoint. “Send an alert to operations” might mean a mailbox, a duty phone, a webhook receiver or an escalation application. Write the address or approved system identifier into the private work record, not a public incident summary.

Walk the route one step at a time

• Was the chosen channel enabled on the active rule and plan?
• Was the intended recipient configured at the event time?
• Does the application show a send attempt or failure?
• Does the receiving system show an accepted message, a rejection or nothing?
• Did the human recipient acknowledge it under the local procedure?

Where evidence is missing, ask support rather than treating an absent log as proof of successful delivery. If a webhook is involved, follow the supplier's signing and retry instructions — and don't turn off verification as a routine fix.

Distinguish notification from escalation

An alert landing in a mailbox is not the same as an emergency workflow reaching a responder. Coram describes configurable escalation, including 911 when configured, in its separate emergency-management application V05. Pano describes analyst-confirmed wildfire incidents sent to response partners by configured email or SMS V12. These are specific documented workflows; neither tells you how an unrelated gate system behaves.

Keep the supplier's configuration and your organization's approved response plan together, and make sure a test never trips a real emergency call by accident. Arrange any escalation exercise with the responsible team and use the designated test route.

Put useful times on the test sheet

Record when the annotated rule first qualifies, when the application creates the event, when sending is attempted, when the chosen endpoint receives it and when staff acknowledge it. Our proposed alert-delay measure runs from qualification to endpoint receipt M02. Acknowledgment is a separate operating measurement.

Take a hypothetical run: qualification at 01:42:00 and endpoint receipt at 01:42:24 gives 24 seconds of measured delivery delay. If the operator acknowledges at 01:44:00, the additional wait is 96 seconds. Report both numbers instead of calling the whole two minutes detector latency.

Retest recovery, then leave a handover

Use the approved test event and recipient. Keep the failed test and the successful retest in the record with the changed setting, and add an owner and a due time if any step remains unresolved. A green “sent” badge settles nothing about what happened at the receiving endpoint.

The handover sheet covers open faults, and the camera-offline checklist covers a view that stopped updating. Use the branch that matches the evidence instead of changing camera settings for every missing notification.

FAQ

How many successful tests are enough?

Set the acceptance conditions before the exercise, and include a rejected or unavailable endpoint if the approved test arrangement permits it. This guide has no evidence for a universal sample count.

Should we advertise our fastest observed result?

Keep every eligible test result, the observation gaps and the chosen start/end definitions on file. One fastest run does not describe the delay distribution a buyer will experience.