Statuser

Returns the chronological event log of an incident: status changes, notifications sent (email/Telegram/MAX/webhooks), comments, page screenshots and network diagnostics. Useful for audits and timeline rendering. Every event has a `type` and a matching `meta`: `start`/`end` — no meta; `error`/`resolved` — check location and error code; `notification` — channel, recipient, delivery status; `comment` — text and attachments; `screenshot` — public URL of the page snapshot captured during the outage; `diagnostics` — the location diagnostics ran from and which blocks were collected (`headers`, `body`…

Downloads a ready-to-attach PDF report for the incident. Returns metadata plus the base64-encoded file. Section composition is controlled by `sections` (`ai_summary`, `diagnostics`, `technical_reference`, `events`). Requires `incident_report_enabled` on the plan — otherwise 403.

Diagnostics of an incident of a `scenario` monitor: the run that opened it — location, duration, the failed test, the Playwright error with its call log and the test console output — and whether a screenshot, video and trace were saved. The files themselves open on the incident page in the panel. Recorded once, by the run that opened the incident; 404 for incidents of other protocols.

Shortcut: returns the monitor linked to a given incident in one call.

Lists incidents. Without `server_id` — across the whole account, sorted by start time desc; with `server_id` — only that monitor. `status` and `project_id` filters apply only to the account-wide form. Time depth is limited by the `incident_retention_days` plan feature.

Submits feedback on the AI summary: `positive` or `negative`. Pass `rating: null` to clear a previously set rating.

Returns a pair of deeplinks: `link_user` (open in personal MAX chat with the bot) and `link_group` (add the bot to a group and follow the link). After confirmation, the MAX chat/account becomes available as a notifications channel. Repeated calls before the link is consumed are idempotent — same links are returned.

Returns all MAX accounts and group chats linked to the Statuser account, with status and the "used for 2FA" flag. Available as a notification channel in notification rules.

Switches which linked MAX account receives second-factor confirmation codes. Must be one of the accounts already linked to the Statuser account.

Unlinks a MAX account from the Statuser account. Notifications will stop going to it; notification rules stop including it. If the account was the 2FA channel, its 2FA role is cleared automatically — but it is recommended to first switch the second factor via another channel if no other 2FA channel is configured.

Creates a new monitor. Only `host` and `protocol` are required (plus `scenario_script` for `scenario`) — timeout, interval and redirect handling fall back to the same defaults the panel uses (30 s, 300 s — 900 s for a scenario, redirects followed for `http`/`keyword`), and the paid SSL and domain checks stay off unless asked for. Returns 403 if the account is over the servers limit or if a requested feature is not on the current plan (DNS/keyword/heartbeat, AI monitoring and its model response check as two separate gates, scenarios with their own limit, minimum interval and maximum timeout, la…

Permanently deletes a monitor with its history, incidents and alert settings. Irreversible. To pause checks temporarily, use `monitor_pause` instead.

Returns full configuration and latest status for one monitor by id.

Returns aggregated check results for the period, suitable for uptime/latency graphs. Defaults to the last 24h if `start_date`/`end_date` are omitted. For day-scale periods, the response also contains the last few raw points to keep the graph interactive between aggregation intervals.

Returns diffs of DNS records observed by the monitor: what was added, what was removed, per record type. History depth is limited by the `dns_history_retention_days` plan feature. Only populated for monitors with `protocol = "dns"`; others return an empty array.

Returns heartbeat events (pings from an external system) aggregated into equal intervals over the period. Only meaningful for monitors with `protocol = "heartbeat"`; others return an empty array. Defaults to the last 24h.

Whether an on-demand run started by `monitor_run_scenario` is still going, and its result once it finished within the last hour. Scheduled runs are not here: their outcome is the graph (`monitor_get_checks`) and, for a failure, the incident diagnostics (`incident_get_scenario_details`).

Lists every monitor on the account with current status and configuration. Use `limit`/`offset` to paginate — recommended for accounts with many monitors.

Pauses (`action = "pause"`) or resumes (`action = "unpause"`) checks for a monitor without deleting its configuration or history. On resume, plan-feature gating is re-evaluated.

Runs the saved Playwright test of a `scenario` monitor now, off schedule, with the same consequences as a scheduled run: a point on the graph, and an incident opened or closed. Waits for the run to finish — up to the monitor `request_timeout` plus browser start-up — and returns the verdict, the failed test, the Playwright error and the test console output. The screenshot, video and trace links in the response work for an hour. One on-demand run per account at a time and at most 30 in 10 minutes (409 and 429 otherwise). If the client gives up waiting, `monitor_get_scenario_run_latest` returns t…

Fires a test notification through all channels configured for this account (email/Telegram/MAX per notification rules + webhooks subscribed to the matching type). Useful for verifying delivery without waiting for a real incident.

Partial update: pass only the fields you want to change. Plan-feature constraints from `monitor_create` apply on update too.

Adds a new email address and immediately sends a confirmation code to it. The address becomes effective for notification rules only after confirmation via `notification_email_confirm`. Returns 409 if the address is already confirmed; 429 if a code was just sent; 403 if the per-account limit is reached.

Verifies the code received by email and marks the address as confirmed. Wrong, expired or attempts-exhausted code returns 403; in that case the code is invalidated and a new one must be requested via `notification_email_resend`.

Lists every email address added to the account for notifications, with confirmation status. Notifications go only to confirmed addresses; unconfirmed ones are shown for UX but are not used by notification rules.

Removes an email address from the notification recipients list. Rules that included this address stop delivering to it. Irreversible — to use the same address again, it must be added and confirmed once more.

Resends the confirmation letter to an unconfirmed email. If the address is already confirmed — 409; if you call too often — 429 (wait for cooldown).

Returns the current matrix of notification rules: for each subscription type (`service_alerts`, `ssl_alerts`, `domain_alerts`, `dns_alerts`, `blocklist_alerts`, `weekly_reports`, `updates`, `billing_alerts`, `holiday_mode`, `api_key_alerts`, `security_alerts`, `ideas`) — boolean flags `email` / `telegram` / `max` and one per work chat (`mattermost`, `rocketchat`, `pachca`, `discord`, `slack`) indicating whether that kind of channel gets the event. Account-level types are off for work chats by default: a work chat is usually shared with a team or a client. Every rule carries a `scope`: monitori…

Creates or updates the rule for a single subscription type: toggles channels `email`, `telegram`, `max` and, optionally, the work chats `mattermost`, `rocketchat`, `pachca`, `discord`, `slack` — a work-chat flag that is not passed stays as it is. Selecting individual recipients or chats is not possible — the toggle is on/off per kind of channel; which exact addresses and chats a project uses is decided by `project_channel_set`. Monitoring types apply to ONE project (the oldest one unless `project_id` says otherwise), account types (`billing_alerts`, `security_alerts`, `api_key_alerts`, `update…

Returns the public Statuser plan catalog with prices, limits and features. No authentication required.

Lists the notification channels of the account (confirmed emails, linked Telegram and MAX chats, work chats — `type: chat_webhook` with the chat in `provider`: Mattermost, Rocket.Chat, Pachca, Discord, Slack) together with whether this project uses them. A channel is connected once for the whole account; a project only switches it on or off for its own monitoring notifications. Account-level notifications — invoices, security, API keys — reach every channel regardless of this setting. Webhooks are not here: their scope is stored on the subscription, see `webhook_update`.

Turns one notification channel on or off for this project and returns the full updated list. Affects monitoring notifications only. Switching a channel off here does not disconnect it from the account — other projects keep using it.

Creates a project. Returns 403 when the plan limit is reached (1 on Free, 3 on Pro, 20 on Team) — monitors and status pages are counted per account, so a new project does not raise those limits. A new project starts with every notification channel switched OFF: monitoring notifications go nowhere until `project_channel_set` enables them. That is deliberate — a project is usually created for a new client, and channels enabled by default would send their alerts into somebody else’s chat.

Deletes a project. The last project of an account cannot be deleted (409) — it is where records created without a project go. A project that still holds monitors or status pages needs `move_to_project_id`, otherwise the call returns 409: content moves, settings do not. The notification rules, channel switches and webhook subscriptions of the deleted project are gone for good, and the moved monitors start living by the rules of the destination project — their alerts may end up in a different channel.

Lists the projects of the account, oldest first by id. A project owns monitors, status pages and monitoring notification rules; notification channels, billing and API keys belong to the account as a whole. Every account has at least one project. Calls that take no `project_id` read the whole account and write into the oldest project — use this tool to learn which one that is.

Sets the order projects are listed in inside the panel. Pass every project id of the account in the wanted order — a partial list is rejected (400). Cosmetic: the order changes nothing about delivery or about which project receives records created without one (that is always the oldest project).

Renames a project. Only the name can be changed here — moving content between projects is done through `monitor_update` and `status_page_update`.

Publishes a banner announcement on the status page: `title`, `body`, optional `type` (defaults to `info`), optional display window and link. If `started_at`/`ended_at` are omitted, the announcement is shown until it is deleted or ended. Announcements require a plan with `status_page_announcements_enabled` — otherwise 403 `status_page_announcement_not_allowed`.

Removes an announcement from the status page. Irreversible.

Lists announcements (banner notices shown on top of the public status page): title, body, type/severity, optional display window (`started_at`/`ended_at`) and optional link. Includes scheduled, active and ended entries — filter by time on the client side.

Edits an announcement: `title`, `body`, `type`, display window and link. Pass `null` for `started_at`, `ended_at` or `link` to clear them. To stop an active announcement immediately, set `ended_at` to the current time.

Returns `{ available, cname_valid }` for the given domain: whether the domain is free and whether its CNAME points to Statuser. Useful before attaching a custom domain.

Returns `{ available: boolean }` for the given slug. Useful before creating or renaming a status page.

Creates a public status page. `name` is required. If `slug` is omitted, a random one is generated. Plan-feature constraints apply for custom domain, password, indexing control, white-label, extended timeline and minimum incident duration. Account-level limit is `status_pages_limit` — 403 on overflow.

Permanently deletes a status page with its settings, groups and custom-domain binding. Irreversible. To hide a page without deleting, use `status_page_publish` with `action = "unpublished"`.

Returns the full configuration of one status page by id: settings, groups, linked monitors and custom domains.

Removes the incident report from a status page with all its updates. Irreversible. Underlying monitors and incidents in Statuser are not affected — only the public publication is removed.

Lists incident reports published on a status page with their title, linked monitors, per-server affect statuses and the timeline of updates.

Publishes a new incident report on a status page: title, initial timeline message, start time and per-server impact (`servers`). Optionally link to existing Statuser incidents via `incident_ids` so the report aggregates their data. Add subsequent timeline updates via `status_page_incident_report_update_add`. Monthly quota: `status_page_incident_reports_per_month_limit` — 403 on overflow.

Edits the report itself: `title` and/or `started_at`. To change per-server impact or post a new message, use `status_page_incident_report_update_add`.

Appends a new timeline message to the incident report and updates per-server impact (`servers`). Each call adds a separate record with its own timestamp. If `published_at` is set, it must not be in the future and not earlier than the report start — otherwise 400.

Removes one timeline message from a report by `update_id`. The report itself and the other messages stay. The initial update (created with the report) cannot be deleted — attempt returns 400; delete the whole report instead.

Edits the text of a previously published timeline message (`message` only). Other fields of the update (timestamp, per-server status) cannot be changed.

Lists all status pages on the account with their full configuration: domain/slug, groups and linked monitors, theme, white-label, password protection, etc.

Removes a planned maintenance entry from a status page with all its updates. Irreversible. If a maintenance is just cancelled, publishing a "cancelled" timeline update is usually preferable — otherwise users will not see the history.

Lists planned maintenances published on a status page: title, description, start/end window, affected monitors and timeline of updates. Includes upcoming and completed entries — filter by time on the client side.

Announces a planned maintenance window on a status page. All fields are required: `title`, `description`, `started_at`, `ended_at` and the list of `servers` (`{ id }[]`). Monthly quota: `status_page_planned_maintenances_per_month_limit` — 403 on overflow.

Edits the maintenance entry itself: title, description, time window, list of affected servers. This does not append a timeline message — use `status_page_maintenance_update_add` for progress updates.

Appends a new message to the maintenance timeline ("started", "in progress", "completed", "postponed"). If `published_at` is omitted, the server stamps "now"; if provided, it must satisfy `started_at <= published_at <= now` — pre-announce updates before the window starts are not supported, and future-dated updates are rejected too.

Removes one timeline message from a planned maintenance by `update_id`. The entry itself and the other messages stay. The initial update (created with the entry) cannot be deleted — attempt returns 400; delete the whole entry instead.

Edits the text of a previously published maintenance timeline message (`message` only).

Switches the page visibility for end users without deleting its configuration. `action = "published"` makes it reachable via slug/domain, `"unpublished"` hides it.

Fully replaces the structure of groups and monitors on the page (idempotent replace, not merge). For each group: `name`, `order`, optional `description`, and `servers` — each item has `server_id` (from `monitor_list`), display `name`, `order`, optional `description`. Pass the existing group `id` to update a group, omit it to create a new one. Anything missing from the payload is removed.

Removes a subscriber from the status page. Irreversible: the person stops receiving emails and can only re-subscribe themselves on the public page. Subscriber ids come from `status_page_subscriber_list`.

Exports all subscribers of a status page as CSV text with columns `email,status,confirmed_at,created_at`. Useful for backups or migrating the audience elsewhere.

Lists visitors subscribed to status page updates by email (they receive emails about incident reports and planned maintenances). Returns each subscriber with `status` (`confirmed`, `pending`, `expired`, `unsubscribed`) and dates, plus `stats`: confirmed/pending counts, `total` (confirmed + pending) and the plan `limit` of active subscribers per page. Requires a plan with `status_page_subscribers_limit > 0` — otherwise the list is empty.

Partial update of status-page settings. Pass only the fields you want to change. Slug/domain conflicts → 409; plan-feature constraints → 403.

Returns all Telegram personal accounts and group chats linked to the Statuser account with their settings: chat id, type, username, avatar, 2FA flag, selected topic and available topics for supergroup-forum groups.

Routes Statuser notifications to a specific topic (`message_thread_id`) in a Telegram chat — typically useful for supergroup forums. Pass `message_thread_id: null` to clear the binding and post to the main chat. Use `telegram_linked_list` to discover available topics.

Returns the current state of two-factor authentication: `preferred_method` (active second factor, may be `null`) and `allowed_methods` (which methods are selectable). Allowed values: `email` (always), `totp` (when TOTP is configured), `telegram` (when a Telegram chat is linked), `max` (when a MAX chat is linked).

Registers a new webhook endpoint. Statuser will POST events of the chosen `subscriptions` types. Optionally set a `secret`: Statuser will sign payloads with it so the receiver can verify origin. Requires `webhook_notifications_enabled` on the plan.

Removes a webhook endpoint. Statuser will stop sending events to it. To stop only some event types without deleting, use `webhook_update` and shrink the `subscriptions` list.

Lists all webhook endpoints configured on the account: name, URL, and the set of `subscriptions` (event types delivered to that webhook). The secret set on creation is not returned.

Sends a test payload (flagged as a test) to the webhook to verify availability, signature handling and receiver behavior. On delivery failure returns 502 with details (`reason`, `webhook_status`) — handy for debugging integrations.

Partial update of an existing webhook. Pass only the fields you want to change. Pass `secret: null` to clear the signing secret. Once changed, signatures are computed with the new value — update the receiver accordingly.