Docs
API referenceOperations
Monitor
kind values include checks such as HTTP, SSL, TCP, and heartbeat. The config object is kind-specific; use OpenAPI or MCP search for the current schema before writing. For common detector classes, list monitor templates and call createFromTemplate with the returned input keys. A create above the plan’s monitor or heartbeat monitor limit, or of a monitor kind the plan does not include, returns 403. See plan limits.
For http and keyword monitors, config.regions lists the check locations (us-west, us-east, eu-west, eu-east, asia-pacific, oceania; older codes such as iad resolve to them, and auto keeps one default check) and config.confirmation.requiredLocations sets how many must fail in one interval before the monitor fails (default 2). Each location counts as one check. A write with more locations than the plan allows returns 403. See Check from several locations.
monitors.listChecks returns stored checks, newest first. Query: limit (1-100, default 20), failing_only, and region (a location id). Each check has region, regionLabel, checkColo (the data center code), and, for a failed http or keyword check, evidence with dns, tcp, tls, and http (status, redacted headers, and the first 2 KB of a text body), plus failedLocations and requiredLocations.
A monitor’s status is healthy, degraded, failed, or paused. A disabled monitor (enabled: false) always reports paused, whatever its last check returned, so the status=failed filter lists only monitors that are running and failing.
Backtest a query monitor
monitors.backtest replays a draft query monitor over the last 24 hours or the last 7 days of
real data. It uses the same evaluation as a live monitor. It saves nothing. It reads the same
telemetry as the logs, events, and metrics endpoints, so it needs monitors:read and
errors:read.
config has the same shape as the config of a query monitor in monitors.create.
failureThreshold, recoveryThreshold, and intervalMinutes default to 3, 2, and 5. range is
24h (the default) or 7d.
A check without enough data has
outcome: "not_evaluated" and a reason: after_watermark,
incomplete_bucket, insufficient_history, or baseline_unavailable. summary.not_evaluated
counts these checks by reason. A backtest replays at most 7 days, and the rule window can be at most
7 days. It uses the query budget of the project; a 503 response means you should try again later.
Each read has a byte and time limit. A backtest that passes it returns outcome: "budget_exceeded";
try the last 24 hours or a narrower query.
A percentile (p95, p99, Web Vitals p75) over a window wider than one time bucket can only be
estimated from the values of each bucket. For these rules authoritative is false: the points
show the estimated values, but the backtest does not claim how many alerts would have opened.
Request latency (source: "traces", aggregation p50, p95, or p99) is the exception: each
check reads its percentile over every request of its whole window, the same way the live check
reads it, so the result is exact and authoritative is true. Its window can be at most 288 check
intervals long. See Alert on request latency.
Monitor noise evaluations
Squasher evaluates enabled monitors every hour to score whether they are earning their interruptions, and exposes the result throughmonitors.listEvaluations. Each row reports how many incidents the monitor opened over the trailing window, how many of those actually reached a human, how many anyone acted on, how many cleared on their own, and the median time they stayed open — plus a recommendation and a plain-language rationale.
Every conclusion is scoped to incidents whose opening alert produced a successful notification delivery (
delivered_count), so a broken notification route can never be misread as an unwanted monitor. Check confidence before acting — low means the sample does not support a change.
Agent-driven tuning
Tuning defaults torecommend. The hourly watcher uses monitor history, telemetry, notification delivery, and engineering-response signals to investigate current candidates. Before suggesting a threshold change, it replays historical checks and rejects any proposal that would have missed an incident associated with an engineering response.
The monitors dashboard is the recommendation inbox: safe threshold or attention fixes can be applied in one click, while target, query, severity, disable, and code changes always remain human-owned. Attention fixes fail closed unless a monitor-specific digest route can deliver every opened incident through an enabled supported destination. Slack incident messages link to the same evidence and approval control. Slack buttons never mutate configuration through a GET.
For every effective threshold override, Squasher compares equal before-and-after observation windows and reports outcomes plus outcome_summary from monitors.getTuningSettings. Outcomes remain pending until enough evidence arrives, and then resolve to beneficial, neutral, harmful, or insufficient_data. A change cannot be counted as beneficial when engineering-response signals increase. Attention-routing changes remain insufficient_data until interruption-delivery outcomes are available.
Modes are off, recommend, and auto, at both project and monitor scope. Turning tuning off immediately reverts active overrides. Auto mode is deliberately narrow: it can only widen failureThreshold, never disable a monitor or rewrite its target, query, severity, or declared config. The effective override is separate, visible, reversible, and expires after 1–30 days. A real monitor edit permanently locks tuning and immediately reverts an active override; an identical declarative upsertByName sync is a no-op and does not lock it.
Project settings include daily budget, per-investigation budget, and daily investigation limits. Defaults are $1 per project per day, $0.25 per investigation, and five investigations per day. The accepted maxima are $5 per project per day, $0.50 per investigation, and 20 investigations per day. Reaching a configured limit pauses new investigations without interrupting monitor execution or existing alerts.
CLI and MCP
Usesquasher monitors ... for terminal workflows. squasher monitors backtest --project <project_id> --config @monitor.json backtests a draft query monitor. squasher monitors evaluate --project <project_id> --actionable shows live recommendations. squasher monitors tuning show --project <project_id> <monitor_id> shows declared and effective config; tuning configure, tuning investigate, and tuning act control the bounded workflow. In MCP Code Mode, call search("monitor tuning"). Treat tuning writes as confirmation-required.