---
title: Notification history
description: The delivery log of every alert WatchFor sent, failed to send or silenced — per channel and per incident, with filters and an API.
canonical: https://watchfor.io/docs/notifications/history
---

# Notification history

The delivery log of every alert WatchFor sent, failed to send or silenced — per channel and per incident, with filters and an API.

When someone asks "did we get paged for that?", the notification history
answers it. Every delivery attempt is recorded — **sent**, **failed** (with
the error) or **silenced** — so you can confirm who was notified, debug a
channel that stopped working, or audit what went out during a past incident.

Find it under **Alerting → Channels & contacts → Delivery log**.

## What is recorded

One row per **incident × channel** attempt:

| Column | What it shows |
| --- | --- |
| **Status** | ✅ **Sent** — the destination accepted it. ❌ **Failed** — after the retry the destination refused or was unreachable; hover the badge for the exact error (HTTP status, "connection refused", …). 🔇 **Silenced** — the incident was live but the monitor was [muted](/docs/notifications#muting-a-monitor) or inside a [maintenance window](/docs/monitors/maintenance), so nothing was sent. |
| **Time** | When the attempt happened, relative and exact, in your profile's time zone and format. |
| **Channel** | The channel's name and type. Hover a **Webhook** channel to see its destination URL (webhook URLs of chat channels stay masked). |
| **Severity** | The incident's severity. |
| **Monitor** | Name and target, linking to the monitor. |
| **Incident** | The alert rule's human-readable name (not an opaque id) and the incident number, linking to the incident. |

Some details worth knowing:

- Both the opening notification and the recovery are logged, as are
  [repeat reminders](/docs/alerting#repeat-reminders).
- When several incidents were delivered as one
  [grouped summary](/docs/notifications#grouping-during-a-storm), each
  incident still gets its own row with the same outcome.
- [On-call escalation](/docs/alerting/on-call) pages to individuals are
  recorded too, by the personal method used (email, Telegram, …); the
  monitor's **Recent notifications** card labels them *On-call page*.
- Test notifications are not recorded — their result is shown to you
  directly when you run the test.
- A channel deleted later keeps its historical rows (shown by type).
- Rows are kept for as long as the monitor exists; deleting a monitor removes
  its incidents and their delivery records.

## Filtering and searching

- **Status** — all / Sent / Failed / Silenced. *Failed* is the first place to
  look when a channel goes quiet.
- **Channel type** — every type that appears in your history.
- **Monitor** — one monitor, or all. Opening history from a monitor's
  Alerting tab (**Recent notifications → View all**) pre-selects it.
- **Search** — matches channel name or type, monitor name or target, the
  incident text, the error message, or a webhook URL.

Every monitor's **Alerting** tab also shows a **Recent notifications** card
with the last few attempts for that monitor.

## Why it's useful

- **Confirm delivery** — verify the right people were actually notified, and
  when.
- **Debug a channel** — a run of *Failed* rows with "returned 404" means the
  webhook was deleted on the other side; "connection refused" means your
  endpoint is down.
- **Debug routing** — no row at all for a channel means the incident never
  routed to it; check the monitor's Notification Targets and the channel's
  groups and severity filter (see
  [contact groups](/docs/notifications/contact-groups#how-groups-connect-monitors-to-channels)).
- **Audit** — reconstruct what went out, where, during a past incident.

> **Info**
>
> Notification history is about **what was sent**. For *who changed what*
> across your whole organization, see the
> [activity log](/docs/organization/activity-log).

## Also via API

The same log is available as `GET /v1/notifications`, cursor-paginated with
`status`, `channel_type`, `monitor_id`, `incident_id` and time filters (see
the [resource list](/docs/api#resources)), as the `list_notifications` tool on
the [MCP server](/docs/api/mcp), and through A2A — so an AI agent can answer
"did the Slack alert actually go out?" for you.

---

Canonical page: https://watchfor.io/docs/notifications/history · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt