Skip to main content
Find out the moment something crosses your line, on the channel your team already watches, instead of hearing about it from a customer. Set a rule once and Failproof AI Observability checks it on a schedule, then pages you by email, Slack, webhook, or right in the dashboard. The Alerts page: a grid of alert-rule cards, each showing its trigger, evaluation window, channels, and an info, warning, or critical severity badge Every alert rule at a glance: what it watches, how often, where it pages, and how urgent.

​
Hear about problems before your users do

Stop refreshing a dashboard hoping to catch a regression. Reach for an alert whenever there is a signal you would want to hear about even when nobody is looking, and have it land where you already are:
  • Email, to whoever should know.
  • Slack, a rich message with a button that jumps straight to the incident.
  • Webhook, a JSON POST for PagerDuty, Opsgenie, or your own endpoint, with an optional signature so the receiver can trust it.
  • In-dashboard, quiet by design, for when you are tuning a rule and do not want to page anyone yet.
Attach any combination to a single rule, and its severity (info, warning, or critical) rides along so the urgent ones look urgent.

​
Build the rule in a form, not JSON

You describe what “broken” means in a form, and Failproof AI Observability writes the underlying rule for you. The JSON spec is just what that form produces under the hood, so you can read it to understand a rule but you rarely type it. The new-alert form: name and description, an enabled toggle, and a trigger picker offering metric threshold, custom SQL, evaluation score, compound eval, and per-event conditions Pick a trigger and the form swaps in the right fields; Save writes the rule. The happy path is quick: name it, pick a trigger (what to watch), set the threshold and window (how bad, over how long), attach at least one channel, then Save and hit Test to fire a synthetic notification and confirm every destination is wired up. Under the hood that produces a small spec like:
You are not limited to one kind of signal. Pick the trigger that matches how you think about the failure: Already staring at a failure on the Errors page? Every row there has a + alert button that opens this same form prefilled to catch that exact failure again, so the incident you just triaged becomes the one that pages you next time. Where to find it: Alerts live at /<org-slug>/alerts. Creating, editing, deleting, and testing rules needs alerts:write; alerts:read is enough to look. The recipient picker lists your org’s members by name, so you can page a person without leaving the form.

​
Page me only when it is real

One bad measurement should not wake you. The M of N noise filter controls how many of the last few checks must fail before the alert actually pages you. Set it to 3 of 5 and the rule fires only after it has breached three of its last five checks, so a jittery signal stops crying wolf; leave it at the default 1 of 1 to fire on the first breach. You also choose how often the rule runs, from presets of 1m, 5m, 15m, and 1h, matched to how fast the signal really moves.

​
What happens when an alert fires

A breach opens an incident and pages your channels once. From there your team acknowledges it, assigns an owner, talks it through, and resolves it, all against a clean, attributed record. That triage workflow has its own home: see Incidents.
  • Incidents: track a firing alert from open to acknowledged to resolved.
  • Error tracking: group agent failures and promote one to an alert in a click.
  • Dashboards: watch the shared boards the thresholds you alert on come from.
  • CLI and agents: create alerts and ack incidents from your terminal, or script them into CI.