---
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 sends are recorded too**, sent or failed, with a **Test** badge and
  who sent them in place of the incident link — so "did the test actually
  reach Slack?" has an answer after the toast is gone. Channel tests show in
  the organization-wide log; a monitor's routing test also shows in that
  monitor's history. Test rows are kept for 90 days and are not part of
  `GET /v1/notifications`, which lists incident deliveries only.
- 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
  alert rule and incident text, the error message, and for test sends who
  sent them. It runs on the server over the whole history, so the count
  shows every matching row, not just the loaded page.

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