# Alerts and incidents

When something starts going wrong on a site, Monitor opens an incident and decides whether to tell anyone. An incident is one event, such as “40 pages started returning 404”, however many pages it touches. The **Alerts** tab lists a site’s incidents, and alert emails are sent about them.

> **Before you start:** Monitor must be enabled for your workspace. It is set up by arrangement, so if you do not see the **Monitor** icon in the top bar, [contact us](/contact/). To also receive alerts in Slack, Slack must be connected in your workspace settings.

## One problem, one incident

Monitor bundles findings: one check failing on 100 pages is one incident with 100 pages, not 100 alerts. A single check round sends each recipient at most one email per workspace, however many incidents or sites it covers. The same bundling applies to changes, so a template change that rewrites every title opens one incident.

## How an incident behaves

1. **It opens** when a check starts failing, or when a watched value changes. See [Issues and severity](/docs/issues-and-severity/) and [Changes and diffs](/docs/changes-and-diffs/).
2. **It grows** as more pages are affected, and pages drop off as they recover.
3. **It closes** when every page has recovered. It also closes after 24 hours with no newly affected and no newly recovered pages, even if some pages are still affected. The finding is still listed on the **Issues** tab.
4. **It stays listed.** Closed incidents remain on the **Alerts** tab for a week.

If a finding that closed this way is still there, Monitor does not email about it again unless it has grown.

Open an incident to see how many pages are **Affected** and how many have **Reverted**, when it was **Detected**, when it **Closed** or had its **Last change**, the **Was** and **Now** values for a change, and **What to do**.

## What emails you by default

Every new site starts with these alert rules:

| Rule | Why it is on |
| --- | --- |
| **The site is not responding** | The site is down |
| **robots.txt blocks search engines from the entire site** | The whole site is leaving search |
| **The TLS certificate expires soon** | An outage with a known date |
| **A page that earns traffic has broken** | A page that brings in search traffic has broken |
| **Not indexable** | Pages leaving the index. Set so one deliberate `noindex` stays quiet but a template-wide one does not |
| **Analytics tracking removed** | Measurement has stopped on a page |
| **Any incident** | Anything else severe enough, at the least sensitive setting |

On top of the rules, the site-wide setting **Only when it is at least** is **warning** by default, so Info findings are never emailed unless you lower it.

Alerts go to everyone in the workspace until you choose recipients.

Nothing is emailed while a site’s first pass is running. Page problems found during it are never emailed: they are the site’s existing condition. Whole-site problems, such as the site not responding, are emailed when the first pass finishes if they are still open.

## Change who is told and when

All alert settings are on the site’s **Settings** tab, under **Alerts**.

### Add or edit an alert rule

A rule decides, for one kind of finding, how widespread it must be before anyone is emailed.

1. Under **Alert rules**, select **Add rule**, or **Edit** on an existing rule.
2. In **Alert on**, choose a check, or **Any incident**.
3. In **Scope**, choose **Whole site** or a segment.
4. Move **Sensitivity** between **only big events** and **almost anything**. The caption under it tells you how many pages it takes to fire on this site. A few important pages count as much as many unimportant ones.
5. Optional: in **Recipients (optional)**, enter email addresses. Leave it empty to use the site’s recipients.
6. Optional: select **Also post to Slack**. Each recipient also gets a Slack direct message, in addition to the email, never instead of it.
7. Select **Save rule**.

A rule for a specific check takes priority over **Any incident**. To remove a rule, select **Delete**.

### Change the site-wide settings

Under **Fallback: when to send**:

| Setting | What it does |
| --- | --- |
| **Email someone when this site has an incident** | Turn off to stop all alert emails for the site. The site is still monitored and incidents are still listed |
| **Only when it is at least** | The lowest severity that is emailed. Applies to every incident, including ones handled by a rule |
| **And affects at least** | Pages that must be affected. Used only for incidents that no rule covers |
| **And one of them is at least this important** | Minimum page importance, from 0 to 10. 0 ignores importance. A value above 10 is not saved. Used only for incidents that no rule covers |
| **Hold non-critical alerts overnight** | Quiet hours, with **From**, **Until** and a timezone. Defaults to 22:00 to 07:00 when turned on |
| **Send non-critical alerts once a day** | A daily digest at the time you set in **At**. Defaults to 09:00 when turned on |
| **Who to tell** | The site’s recipients. Leave empty to email everyone in the workspace |

Every new site has an **Any incident** rule, so **And affects at least** and **And one of them is at least this important** only take effect for page findings if you delete that rule.

Critical incidents are never held by quiet hours or the daily digest.

Select **Save alert settings** when you are done.

## Stop an alert you do not need

If an alert is about something that is fine on your site, stop reporting that finding on the page, in a segment, or across the site. See [Issues and severity](/docs/issues-and-severity/).

## Related

- [Issues and severity](/docs/issues-and-severity/)
- [Changes and diffs](/docs/changes-and-diffs/)
- [Monitor site settings](/docs/monitor-settings/)
- [Slack](/docs/slack-integration/)