Skip to main content
By default a check alerts on the first failing run. A grace period lets a check tolerate a few failures first — so a naturally spiky metric (latency, queue depth, request volume) doesn’t page you over a momentary blip.

​
Two types

  • Consecutive (default) — alert after N failures in a row. Any single success resets the count. Good for “only tell me if it’s been broken for a while.”
  • Within window — alert after N failures inside a rolling window of M minutes, even if they aren’t back-to-back. Good for “tell me if it’s flapping,” where intermittent failures still matter.
So a grace period has up to three parts: whether it’s on, the count (N failures to tolerate), and — for within window — the window (M minutes). For example, with 3 consecutive: a check that goes fail → fail → success never alerts — the success reset the streak. But fail → fail → fail does, on the third one. With 3 within 30 minutes, those three failures trigger an alert even if there were passing runs mixed in, as long as they fell inside the same 30-minute window.

​
When to use it

Use a grace period for metrics that briefly wobble on their own. Don’t use it for must-not-fail checks — data freshness, replication lag, a row that must exist — those should alert immediately.
A grace period delays the alert, not the detection. The check still runs and records each failure; you’ll see it going red in the dashboard before the grace period is exhausted and the alert fires.

​
Setting a grace period

In the app, it’s in the check form’s alerting section. Everywhere else:
Over MCP, create_check and update_check take grace_period_enabled, grace_period, grace_period_type (consecutive / within_window), and grace_period_window. When Alertee’s AI suggests a check for a spiky metric, it sets an appropriate grace period for you.