REST API

Uptime monitors

Writable fields: name, url, interval_seconds, http_method, request_body, timeout_seconds, check_ssl, follow_redirects, expected_status_codes, body_must_contain, body_must_not_contain, confirmation_period_seconds, recovery_period_seconds, headers, request_cookies.

name defaults to the URL when omitted. headers is a JSON object, and request_cookies is a JSON object of cookie names and values sent as a Cookie header. http_method accepts GET, HEAD, POST, PUT and PATCH; request_body is sent with the three that carry a body and is assumed to be JSON unless a Content-Type header says otherwise. Optional group_name assigns a group by name (created if it does not exist); notification_channel_ids sets the channels — omit it on create to use the organization's auto-assign channels.

Cron monitors

Writable fields: name, interval_seconds, grace_seconds, max_runtime_seconds, check_type, allow_overlapping_runs.

interval_seconds has a minimum of 60 (plan minimums apply). check_type is heartbeat or start_end. The same group_name and notification_channel_ids options apply; responses include the ping_token and its ping_path.

Monitor groups

Writable fields: kind, name.

Service and cron groups share these endpoints and are told apart by kind (service or cron). kind is required on writes (as a query or body parameter) because the two id ranges are independent; on the list it is optional. Deleting a group leaves its monitors ungrouped.

Notification channels

Writable fields: name, email_all_users, send_recovery_alert, auto_assign_to_new_monitors.

Recipients are set with user_ids (organization user ids) and integration_ids. When email_all_users is true, specific users are cleared.

Integrations

Writable fields: name, provider, webhook_url, bot_token, chat_id, integration_key, headers, enabled.

provider is one of slack, google_chat, discord, telegram, webhook, ilert and is fixed once set. Webhook-style providers take webhook_url; telegram takes bot_token and chat_id; ilert takes integration_key. The webhook provider also takes headers, a JSON object of request headers sent with every alert. Responses list configured setting names under configured_settings and never include the secret values.

Status pages

Writable fields: name, slug, headline, description, logo, remove_logo, logo_url, favicon, remove_favicon, brand_link_url, theme, accent_color, background_color, font, hide_branding, uptime_days, show_uptime_percentage, show_response_times, access, password, regenerate_access_token, sections.

name and headline are required on create; the public slug is derived from the name. sections sets the layout — an ordered list of sections, each with an optional title, collapsible and collapsed, and monitors given as uptime monitor ids or { id, type, display_name } with type uptime or cron — and replaces the existing layout. service_monitor_ids is shorthand for a single untitled section. Branding fields: theme (light or dark), accent_color, background_color, font (sans, serif or mono), uptime_days (7–90), show_uptime_percentage, show_response_times, and logo and favicon as a base64 data URI or multipart file. hide_branding removes the "Powered by" footer (Pro and Team). access is public, unlisted or password (the last two on Pro and Team); a password page needs password, which is never returned, and regenerate_access_token gives an unlisted page a new key. Responses add access, share_path (with the key for unlisted pages) and subscribers_count. Each page also serves a public status JSON at /status/:slug.json, a badge at /status/:slug/badge and a widget at /status/:slug/embed; see Customize your status page.

Status page incidents

Writable fields: title, description, status, started_at, visible, monitors.

Incidents you post on a status page, distinct from automatic monitor incidents. Each has a timeline of updates; the incident's status (investigating, identified, monitoring or resolved) follows the latest one. monitors lists the affected monitors. On create, status and description become the first update; on update they post a new one.

Incidents

Automatic downtime and cron alerts. Filter the list with status (open or resolved) and monitor_type (ServiceMonitor or CronMonitor). Incidents normally resolve themselves when the monitor recovers; resolve closes one by hand.

Maintenance windows

Writable fields: title, description, starts_at, ends_at, show_on_status_pages, monitors, status.

Planned work on monitors. During a window, incidents that start on the affected monitors send no alerts and don't count as downtime on status pages. With show_on_status_pages the window is announced on every status page that shows one of those monitors. phase (scheduled, in_progress, completed) follows the clock; a completed update ends the window early.

Usage

A read-only summary of the organization's plan, its limits, and how many monitors and status pages are in use.