Start with the event
Open the Inbox from the dashboard toolbar to review up to 20 recent notification deliveries in the active workspace. Search by monitor or event name, then combine a notification type with a delivery status. Failed isolates failed attempts; In progress includes queued and sending notifications. The toolbar badge counts those two categories, not unread messages. Opening a notification does not change its delivery status.
Notifications are grouped by Today, Yesterday, and Earlier. Open one to see its recorded time, delivery explanation, and related incident or certificate. Previous and next controls follow the filtered list; Back to inbox restores your filters and list position. Delivery activity opens the Team delivery view for attempts and recipient details.
A refresh failure keeps the last available activity visible with a stale notice. If workspace access is lost, the inbox clears restricted content until access can be verified again.
Open the affected monitor and incident. Confirm whether the event you expected actually occurred: a confirmed outage or a resolved incident. A single failed check does not necessarily satisfy your configured confirmation policy.
Note the monitor name and event time so you can compare the same incident across the application and the receiver.
Follow the notification path
Did an event occur?
Check whether the incident was confirmed or resolved. A failed check alone may not meet the alert policy.Check the destination
For a broader view, open Alerts → Delivery history. The Failed, Retrying, and Delivered summaries filter recent delivery groups. Search by monitor, event, or recipient and combine that search with an event type or delivery status. Counts reflect this recent, filtered activity rather than lifetime totals. Owners and admins see workspace delivery activity; other members see deliveries addressed to them.
Choose View details to inspect recipient outcomes and recorded errors. A single event can reach one destination and fail at another. Searching for a recipient keeps the complete visible group together so its status and recipient count remain meaningful. Open the monitor name to investigate the incident or certificate.
Use Monitor rules to review notification delays and temporary mutes. Custom delay values remain visible, and paused monitors are identified separately. Members with monitor update permission can change the delay, mute new alerts for one hour, 24 hours, or seven days, and unmute them directly. Muting keeps checks running. Filters and page positions stay in the URL when switching between delivery history and rules.
Open Settings → Integrations → Connected in the affected workspace.
- Confirm that the destination is enabled.
- Check its event subscriptions. A recovery-only destination will not receive an outage message.
- Confirm that the destination points to the channel or application you are inspecting.
- Send a test using Test and read the reported result.
A successful test proves that the test reached the receiver at that moment. It does not prove that a previous event existed, matched the subscription, or was delivered.
Inspect the receiver
Slack
Confirm that the incoming webhook still belongs to the intended channel. If it was revoked or the channel configuration changed, review the connection with the person who manages the Slack app. Follow Slack setup for the destination requirements.
Signed webhooks
Confirm that your endpoint is public HTTPS and satisfies the endpoint requirements. Inspect the response status and receiver logs around the test time.
The receiver must return a 2xx response within ten seconds. Verify the signature using the raw request body before parsing JSON. Check the timestamp and use the signing secret exactly as supplied.
webhook.test. A receiver that only accepts incident event types may reject an otherwise valid connection test.Account for retries
Signed webhook incident deliveries can retry after failure. Deduplicate using X-Uptime-Id, which remains stable across attempts. A retry is another delivery attempt, not another incident.
Connection tests run once. If a test fails, fix the receiver or destination configuration before testing again. See signed webhooks for the retry schedule and verification example.
Ask for help with useful context
Include the monitor name, event time and timezone, destination type, test result, and a short description of the expected behavior. Remove credentials and sensitive request content from logs before sharing them.
Contact the team if the event exists, the destination settings look correct, and the test result does not explain the problem.