Skip to main content
Status monitoring connects checks, incidents, and public communication so the same monitoring workflow can power both response and customer visibility. Basic HTTP and query monitors are available on lower tiers. Advanced protocol checks such as keyword, SSL, DNS, TCP, SMTP, POP3, and IMAP are available on plans that include advanced check types. Monitor checks are included as a monthly quota on every plan. Paid plans can continue running checks beyond the included quota with usage-based check overages, while monitor count remains a plan limit.

​
What you can monitor

  • HTTP health endpoints
  • Heartbeat and cron jobs with a generated heartbeat URL
  • Keyword-based HTTP checks
  • SSL certificate expiration windows
  • Domain and DNS resolution health
  • SMTP, POP3, and IMAP protocol checks
  • TCP port checks
  • Query-backed checks
  • Service-level health for public components

​
Monitor templates

Monitor templates create proven detector classes with one request. Use them when you want the standard checks first, then tune the monitor after it exists.
  • Internal auth failures watches logs for a credential or environment drift phrase.
  • Ingest silent alerts when a selected event source stops sending data.
  • Error burst alerts when level:error log volume crosses a threshold.
  • HTTP health checks a public URL for HTTP 200 and can require a response body snippet.
List templates with GET /v1/projects/{project_id}/monitor-templates or squasher monitors templates --project <project_id>. Create one with POST /v1/projects/{project_id}/monitor-templates/{template_id} or:

​
Alerts and automation

  • Monitor incidents can fan out through webhook-based alert delivery.
  • Heartbeats accept success and failure signals, including explicit failed runs from jobs.
  • Status monitoring still drives incidents and status page rollups from the same monitor state.

​
Incident response workspace

The Incidents page is a response queue with Needs attention, Active, Scheduled, Resolved, and All views. Use Start investigation for internal response work, Declare incident for a known incident, and Schedule maintenance for planned work. Each incident keeps one response record with these views:
  • Response — current impact, response owner, next action, comments, and timeline.
  • Evidence — saved evidence and recent monitor checks.
  • Resolution — diagnosis, fix work, and verification.
  • Communications — notification delivery and deliberate status-page publication.
  • Follow-ups — prevention work after resolution or when follow-up tasks exist.
Starting an investigation or changing its internal status does not publish it to customers. Manual publication starts from Communications → Declare outage. Automatic status-page publication occurs only when an eligible monitor incident matches the configured publication delay.

​
Spike detection

Query monitors can alert on rate spikes instead of fixed thresholds. Use the spike comparator when the current count should be compared to the trailing baseline for the same query. Configure the multiplier, baseline length, and minimum current count so low-volume queries do not page on small samples. For example, a query monitor can fail only when the current 15-minute error count is at least 3x higher than its trailing 7-day baseline and the current window has at least 10 matching events.

​
Investigate an evaluation

The monitor detail page keeps recent evaluation state, failure reasons, measured values, thresholds, and baseline context together. Its recent-evaluations strip makes state changes scannable without opening every check. Hover or focus an evaluation to see its recorded outcome, and use the keyboard-accessible check history for the full recorded evidence.

​
Self-tuning monitors

The monitor detail page shows whether tuning is off, recommendation-only, or auto. It also shows the config you declared beside any temporary effective threshold, the evidence and counterfactual behind a proposal, and controls to apply, reject, or revert it. The system protects real outages before suppressing noise: a threshold proposal must preserve incidents associated with an engineering response, and alert silence only counts when the opening notification was delivered. Auto mode only applies high-confidence threshold widening, changes are rate-limited, and every override expires. A human edit permanently locks that monitor from further system adjustment. Investigation spend is bounded by configurable project budgets and daily investigation limits. Reaching a limit pauses new investigations without changing monitor execution or alert delivery.

​
Plan behavior

  • Free is for proving out basic uptime and a branded public status page.
  • Pro adds production monitor capacity, a public status page, badges, and a custom status domain.
  • Team adds advanced check types, private status pages, maintenance windows, and larger public communication limits.
  • Scale adds custom CSS, SSO, priority support, and the highest status-page and monitor limits.
See the pricing page for the current included check volume, monitor count, status-page limits, and paid overage rates.

​
Regional checks and degraded states

HTTP and keyword monitors can run from multiple configured regions. A single-region failure does not mark the monitor failed when the remaining regions are healthy; the monitor rolls up to failed or degraded only when regional quorum agrees. You can also configure latency thresholds for HTTP-style checks. A successful response that exceeds the degraded threshold appears as Degraded instead of healthy, so public status pages can show partial disruption before a hard failure. For status-page workflows, failed monitor incidents can auto-publish after the configured delay. Squasher generates a customer-facing title and summary from the monitor state and links the update to the status page component backed by that monitor.

​
API, CLI, and MCP access

  • Use the public Query Guide API to discover the best logs, metrics, traces, monitor, and incident endpoints for a project before automating a workflow.
  • Use the Observability Summary API when you want one compact operator-focused payload before drilling into one metric or dashboard query.
  • Use squasher query-guide get, squasher monitors list, squasher monitors templates, squasher monitors create-from-template, squasher monitors create, squasher monitors upsert, and squasher incidents list for script-friendly status workflows.
  • Use squasher observe summary, squasher metrics inspect, and squasher dashboards inspect-query when the next step is an agent-style breakdown instead of a raw export.
  • Use the Squasher MCP search and execute tools when an agent needs the same data without UI-only flows. Search for monitors.create, monitors.upsertByName, monitors.update, status, incident, dashboard, or query operations, then call them through Code Mode.

​
Suggested setup order

  1. Create a status page and define public components.
  2. Add monitors for the services behind those components.
  3. Run checks manually to verify the behavior.
  4. Publish the page when the rollups look correct.

​
Agent handoff

Use this prompt for monitor and incident automation:
Use API, CLI, and MCP access together: Query Guide for discovery, squasher monitors ... for terminal workflows, and MCP search("monitors") then execute for assistant workflows.