Notification rules

A notification rule evaluates a condition on a schedule and fires a notification when the condition is met. Two patterns cover what most teams want:

• Threshold breach: "alert when LCP at p75 goes above 3,000 ms."
• Relative change: "alert when a metric is meaningfully worse than in the previous window."

This guide walks through both. The engine's the same; only the condition looks different.

Time to set up: about ten minutes per rule. You'll need: an organization member account with permission to create rules (any role works for your own rules).

Where rules live

Rules are organization-level resources. Every rule is owned by the user who created it, but other org members can see them too. Notifications go to whatever delivery target the rule specifies (by default, the creator's email).

1. Pick a preset (or start blank)

Open Notifications → Rules → New rule in the fastmon dashboard. The first step shows a list of presets: common rule shapes pre-filled with sensible defaults:

• LCP regression: LCP p75 above the "Good" threshold (2,500 ms) over the last 24 h
• CLS regression: CLS p75 above 0.1
• INP regression: INP p75 above 200 ms
• Traffic drop: pageview count down 50% vs. the previous 24 h
• Error rate too high: more than 1% of pageviews with a JS error
• Page weight bloat: transferred bytes p75 above 3 MB over 7 days

Pick the one closest to what you want. You can edit any field afterward. If nothing matches, choose Blank rule and skip to step 3.

2. Pick a delivery target

Four target types are supported:

• Email: to one or more addresses.
• Slack: native incoming-webhook integration.
• Discord: native incoming-webhook integration.
• Webhook: POST to a URL with a JSON payload. Use this for Teams, Mattermost, PagerDuty, Opsgenie, or any other tool with an incoming-webhook URL.

You can add multiple targets to one rule. Each fires on the same event.

3. Define the condition

The part that takes a bit of thought. A rule has three pieces:

What you're measuring

• A scope: a single site, or a site tag to cover a group of sites with one rule (the rule evaluates each site in the tag separately).
• A metric (LCP, INP, CLS, FCP, TTFB, error rate, pageviews, visitors, …).
• An aggregation (p50, p75, p95, count, avg, …). The visitors and requests metrics are counts, so they only take count.
• For the visitors metric, an optional identity picks which identifier backs the count: stitch (the default, edge-derived, works in every mode) or session (consent-gated). It applies only to visitors.
• An optional filter (mobile only, a specific URL pattern, a country list, …).

When you're measuring it

• A time window: 1 hour, 6 hours, 24 hours, 7 days, or 30 days. Shorter windows catch things faster but are noisier.
• There's no cadence to configure. Fastmon derives the evaluation interval from the window (a fifth of the window, clamped between 1 and 15 minutes), so a 1-hour rule is checked every ~12 minutes and a 24-hour rule every 15.

What's a breach

Pick one of:

• Above / below threshold (absolute): fixed number. "LCP p75 > 3,000 ms."
• Changes against the previous window (relative): compared to the baseline window directly before the current one. "LCP p75 +20%." The baseline defaults to the same length as the measurement window.

Each shape has its own gotcha:

• Absolute thresholds are stable, but they punish you on the day a big new segment hits your site (more slow-network visitors → metrics dip → alert you can't do anything about).
• Relative thresholds are sensitive but noisy on low-volume sites. One bad day-over-day comparison fires the alert. On a low-traffic site, prefer a longer window (7 or 30 days).

4. Dry-run the rule

Before you save, click Evaluate now. That runs the rule against the current window and tells you whether it would fire. Good sanity check for the threshold: if it fires on every test, the threshold is too tight.

There's a corresponding API endpoint: POST /notification-rules/{id}/evaluate.

5. Send a synthetic test

Once the rule is saved, click Send test notification. This sends a sample message to all delivery targets so you can confirm they receive it.

API equivalent: POST /notification-rules/{id}/test.

6. Watch the history

Each rule has a History tab that lists every evaluation, whether it fired, and (if it fired) where the notification went. If you ever get an alert that doesn't match what you see in the dashboard, the history is the audit trail to start from.

A worked example: LCP regression on production

Goal: alert when LCP at p75 on the production site is more than 20% worse than the previous 24 hours.

On a low-volume site, the day-over-day comparison is the piece that bites: one slow overnight period can swing a 24-hour p75 by 20% on its own. If your traffic is thin, widen the window to 7 days before you loosen the threshold.

Common surprises

• Rules fire on the transition, not on every evaluation. A rule notifies when its condition flips from not met to met; while the regression persists, it stays silent. If you want periodic reminders during a long incident, set Re-notify after on the rule; it re-sends after that much time if the condition is still met.
• A regression alert during a known maintenance window is still noise. Pause the rule, or filter by URL to skip the affected paths.
• There are no per-release alert conditions. Rules compare against thresholds or the previous window, not against a release. To judge a specific deploy, use Compare releases after the alert.

Related

• Notification rules API: programmatic creation.
• Releases concept: tagging deploys.
• Compare releases: wire CI/CD to tag deploys.