> ## Documentation Index
> Fetch the complete documentation index at: https://docs.squasher.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Status monitoring

> Create monitors, open incidents, and publish customer-facing status updates from one workflow.

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:

```bash theme={null}
squasher monitors create-from-template --project <project_id> <template_id> --inputs '{"threshold":50}'
```

## 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:

```text theme={null}
Set up or review Squasher status monitoring for project <project_id>. List existing monitors and incidents first, propose a declarative monitor plan, use upsert where names should stay stable, and ask before creating, updating, pausing, or deleting checks.
```

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.

## Related guides

* [Status pages](/features/status-pages)
* [Alerts](/features/alerts)
* [Query Guide API](/api-reference/query-guide)
* [Observability Summary API](/api-reference/observability-summary)