List monitoring checks for the organization, optionally filtered by name/slug substring, labels, or check group. Use this for browsing or filtering a fleet of checks. To investigate a single check's current health, use diagnose_check instead.

Get a single check's metadata by UID or slug. For a full triage briefing (current status + recent results + active incidents), prefer diagnose_check instead.

Create a new monitoring check. If you don't know what config shape a given type expects, call get_check_type_samples first to fetch a working starting config, then use validate_check to dry-run before creating.

Update an existing check by UID or slug. PATCH semantics — only the fields you pass are modified, others stay as-is.

Soft-delete a monitoring check by UID or slug. The check stops running immediately; historical results are kept.

Query monitoring results (raw or aggregated) with filtering by check, type, status, region, period type, and time range. Use this for trend analysis or to inspect a specific window. For investigating a single check's current state, use diagnose_check instead. Defaults: if periodType is omitted it falls back to "hour". If periodStartAfter is omitted it falls back to a window matched to the finest periodType requested (raw=1h, hour=24h, day=30d, month=365d). The response includes effectiveFilter so you can see exactly what filter actually ran.

List incidents (past or active) for the org, optionally filtered by check, state, or time range. For triaging a specific check's incidents in one call, prefer diagnose_check.

Get a single incident by UID. Pass with="events" to also include the timeline of state transitions and notifications.

List who was notified for a given incident, with delivery status.

List integrations (Slack, webhook, email, …) configured for the organization. Use this to discover what notification channels are available before attaching them to a check.

Create a new integration (webhook, email, msteams, …) that can be attached to checks for incident notifications. Slack cannot be created here — install it via the dashboard OAuth flow instead.

List all check groups for the organization. Check groups bundle related checks together for shared incident handling and dashboard organization.

List monitoring regions available to the organization (e.g. eu-west-1, us-east-1). Returns the slug, label, and any per-region metadata. Use these slugs in the regions array of create_check or update_check.

Return everything an operator would want to look at to diagnose a single check's current state in one call: current status, recent raw results across regions, any active incident, and the most recent resolved incident. Use this instead of chaining list_results + list_incidents when a human asks "what's wrong with check X?".

List all status pages for the organization.

Get a single status page by UID or slug.

Create a new status page for the organization. A status page is the public-facing dashboard that displays the current health of selected checks.

Update an existing status page (PATCH semantics — only provided fields change).

Soft-delete a status page by UID or slug.

List sections within a status page. Sections group resources (pinned checks) on the public-facing page.

Create a new section within a status page.

Update a section within a status page (PATCH semantics — only provided fields change).

Delete a section from a status page. Resources in the section are removed too.

List resources (checks pinned to a section) within a status page section.

Pin a check — or a whole check group, rendered as one aggregated component that never lists its members — to a status-page section as a publicly-displayed resource.

Update a status page resource (display name, explanation, position).

Remove a resource (pinned check) from a status-page section.

List the incident publications on a status page — the customer-facing incidents, distinct from the internal incidents the monitoring system opens.

Publish a hand-written incident on a status page. The title and body are shown to CUSTOMERS: never paste probe output, error strings, internal hostnames or IPs into them.

Update a published incident's title, severity or state (PATCH semantics). Any edit marks the publication as human-authored, which stops the auto-resolve pipeline from closing it.

Append a narrative update to a published incident. Updates are APPEND-ONLY — there is no edit or delete. The body is shown to customers: never include probe output or internal names.

Publish an EXISTING internal incident onto a status page. The public title is templated from the page's own public resource name — the incident's internal title, which is built from the check slug, is never exposed.

Unpublish an incident from a status page. The publication row is kept for audit but disappears from the public page, and the same incident can be published again later.

List maintenance windows for the organization, optionally filtered by status. Each window includes a server-computed status (active/upcoming/past) and nextOccurrences (the next concrete activations).

Get a single maintenance window by UID, including title, schedule, recurrence rule, server-computed status (active/upcoming/past), and nextOccurrences (the next concrete activations).

Schedule a new maintenance window. Optionally attach checks in the same call by passing checkUids — the underlying service does this in two steps but the tool handles it for you.

Update a maintenance window (PATCH semantics — only provided fields change).

Delete a maintenance window by UID (soft delete).

Replace the set of checks (and/or check groups) attached to a maintenance window. Pass empty arrays to clear. To leave one of the two collections untouched, pass it with its current contents — partial updates are not supported by this endpoint.

List all monitoring check types supported by this server (e.g. http, tcp, dns, icmp, ssl). Use this first when you don't know what type to use. Then call get_check_type_samples for the chosen type to get a starting config.

Return ready-made sample configs for the given check type. Each sample is a complete, valid config you can clone and modify. Use this to learn the config shape for a type — much more reliable than guessing field names.

Dry-run validate a check config without creating the check. Returns {valid: true} on success or {valid: false, fields: [...]} listing the specific fields with errors. Use this before create_check when you've assembled a config from scratch or modified a sample, to catch problems early.