Reference

Monitors and alerts

Six scheduled checks with in-app, email and webhook delivery, and a stored history you can diff.

What a monitor is not

A monitor is not a crawler and not a watchdog for your uptime. It re-runs one analysis on a cadence and tells you when the answer changed. It reads the same data your agent reads; it does not watch your server or your rankings in real time.

The six checks

CheckTriggers whenAlert severity
health_scoreThe score drops by more than your threshold, or sits below your floorwarning, critical at 2x the drop
content_decayA page crosses the decline threshold that was not declining last runwarning, critical above 100 clicks lost
ctr_gapThe count of high-impression low-CTR queries grows past your thresholdwarning, critical at 3x
index_coverageA page that was indexed on the last run is no longer indexedwarning, critical at 3 pages
keyword_gapA tracked competitor ranks for a keyword you do notinfo, warning at 5 or more
rival_moverA competitor gains net keywords on the checked set between runsinfo, warning at 3 or more

Cadence and timing

Daily, weekly and monthly. A missed window delays a run rather than firing a catch-up burst, and a run that fails still advances the next run so one broken check cannot wedge the queue.

A new monitor is scheduled an hour out rather than immediately, so creating five does not fire five alerts at once. Use monitor_run_now with dryRun: true to preview the payload first.

Delivery channels

  • inapp — always available, stored as an alert row.
  • email — needs RESEND_API_KEY on the deployment. Without it the monitor creation fails rather than silently dropping mail.
  • webhook — HTTPS only, ten-second timeout, and the payload is documented so you can verify a signature if you want one.

History and diffing

Every evaluation is stored as a snapshot, including the ones that did not trigger. That is what lets the next run answer "is this new?" — and it means you can compare any two runs, or turn any snapshot into a public link.