Statuser

Returns the profile of the current account: `id`, email, name, status, avatar, creation date, password-change date, timezone and the AI-assistant flag. Plan/limit info is not here — use `current_plan_get`.

Takes no parameters.

Partial update of the account profile. Mutable fields: `name`, `timezone`, `is_ai_assistant_enabled`. Pass only the fields you want to change.

Returns the active plan with its price, full `features` object (limits and feature flags), and subscription metadata (`valid_until`, `current_billing_period`, `pending_plan`). Useful to check gates before calling feature-restricted endpoints.

Takes no parameters.

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

Takes no parameters.

Returns the account audit log newest first: who changed what and when — the owner (panel, bots, Statuser AI), API keys (public API, MCP) or the system (plan enforcement, autopay, expirations). Answers questions like "who paused this server", "when was the account logged into", "what did the system disable after a downgrade". Each entry has `action` (stable `<object>.<verb>` code), actor, source, target, masked `changes` (was → became), `details`, `ip` and geo `location`. Depth is limited by the plan window: `retention_days` in the response (`null` = unlimited). Support staff actions are never included.

Downloads the activity log as CSV under the same filters as `activity_log_list` (pagination is ignored). Columns: `id, created_at (UTC), action, actor_type, actor_label, source, target_type, target_id, target_label, ip, country, city, user_agent, changes (JSON), details (JSON)`. At most 50 000 newest rows per call; `truncated: true` in the result means the history is longer — narrow `from`/`to` or filters and repeat. Available on plans with `activity_log_export_enabled` (Team); otherwise fails with `activity_log_export_unavailable`. The export itself is recorded in the log as `activity_log.export`. Prefer `activity_log_list` for questions — use this tool only when the user explicitly wants a file or a full dump.

Returns the current state of "holiday/vacation" mode: if active, `holiday_until` contains the end timestamp; otherwise `null`. While active, Statuser does not send personal incident notifications (checks still run and incidents are still recorded).

Takes no parameters.

Enables holiday mode until the given timestamp (`holiday_until` in ISO 8601) or disables it if `holiday_until` is omitted. While active, personal notifications are suppressed; monitors keep running and incidents are still recorded.

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).

Takes no parameters.

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. A non-null `disabled_reason` means the messenger refuses delivery to this chat (`bot_blocked`, `user_deactivated`, `chat_not_found`, `bot_kicked`, `no_rights`): no notifications go there. It is fixed in the messenger and confirmed by a channel test in the Statuser panel.

Takes no parameters.

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 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. A non-null `disabled_reason` means the messenger refuses delivery to this chat (`bot_blocked`, `user_deactivated`, `chat_not_found`, `bot_kicked`, `no_rights`): no notifications go there. It is fixed in the messenger and confirmed by a channel test in the Statuser panel.

Takes no parameters.

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.

Takes no parameters.

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.

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

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.

Takes no parameters.

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.

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

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.

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).

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`. A work chat with `is_disabled_by_plan: true` receives nothing on the current plan; its on/off state in projects is kept and applies again after an upgrade. A Telegram or MAX channel with a non-null `disabled_reason` receives nothing either, even when switched on here: the messenger refuses delivery until the chat is fixed and a channel test in the Statuser panel succeeds.

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.

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

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

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, latency alerts, custom success codes, non-default locations, blocklist monitoring, incident confirmation delay).

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

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.

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

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.

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 the result.

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`).

Runs a Playwright test in the Statuser sandbox exactly like a scheduled scenario run, without creating or changing a monitor: no point on the graph, no incident. Use it to check a script before `monitor_create`/`monitor_update`. Waits for the run to finish — up to `request_timeout` plus browser start-up — and returns the verdict (`passed`, `failed`, `timed_out`, or `runner_error` when the sandbox could not run it; that one does not count towards the limit), the failed test, the Playwright error, the console output, and screenshot, video and trace links that work for an hour. Requires `scenarios_limit` above zero on the current plan. One on-demand run per account at a time and at most 30 test runs in 10 minutes (409 and 429 otherwise).

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 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.

Sends a heartbeat signal to a `heartbeat` monitor, as the external job itself would — to check the setup or to close an incident by hand. A normal signal records the job as alive and closes an open incident; `fail: true` reports a failed run and opens an incident right away. A paused monitor accepts the signal and ignores it. The job itself calls `https://api.statuser.cloud/v1/heartbeat/<heartbeat_token>` (and `/fail`) with GET, POST or HEAD and needs no API key.

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.

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.

Returns a detailed incident card: status, start/end time, root cause, keyword, replay link, plus screenshot and per-location network diagnostics (headers, body, OpenSSL, ping/nmap/mtr/traceroute, timings). `screenshot` is only returned when `screenshots_enabled` is on the plan; `details` — only when `network_diagnostics_enabled`.

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`, `timing`, `resolved_ips`, `ping`, `traceroute`, `mtr`, `nmap`, `openssl`). `screenshot` and `diagnostics` events are only returned on plans with `screenshots_enabled` / `network_diagnostics_enabled`; `screenshot` also requires an HTTP monitor and only exists for incidents started after 2026-08-09.

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

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.

Generates (or returns the cached) AI summary of the incident — a short human-readable explanation of what happened and why, based on diagnostics. Idempotent: repeated calls return the same summary. Requires `network_diagnostics_enabled` on the plan.

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

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.

Permanently deletes an incident together with its network diagnostics, screenshot, comments, AI summary and notification history. Irreversible — always confirm with the user before calling. Uptime and SLA are computed from incidents, so deleting one raises the reported availability of the monitor on status pages and in every report generated afterwards (already issued reports keep their numbers). Only a closed incident can be deleted: an `ongoing` one returns 409 — wait for recovery first, otherwise the next failed check reopens it.

Lists all comments on an incident in chronological order, including attached files and timestamps.

Adds a text comment to an incident. To attach files: either pass URLs already issued via `incident_comment_upload_file`, or pass local file paths in `attached_local_files` and the tool will upload them first. Requires `incident_comments_enabled` on the plan.

Edits text and/or attachments of an existing comment. If `attached_files` is provided, it fully replaces the previous list — files not in the new list are deleted from storage.

Permanently deletes a comment along with all attached files. Irreversible — neither comment nor files can be recovered.

Two-step file upload: requests an upload URL from Statuser, PUTs the local file there, and returns the public `file_url` you can pass into `incident_comment_create` / `incident_comment_update` as an attachment. Size limit: 5 MB.

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

Returns the full configuration of one status page by id: settings, groups, linked monitors and custom domains. A custom domain in status `disabled_by_plan` does not serve the page on the current plan; it stays attached to the page and is verified again after an upgrade.

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

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.

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.

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

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.

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"`.

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.

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.

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`.

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.

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

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.

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 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.

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

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.

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 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. `is_disabled_by_plan: true` means the current plan has no announcements: the entry is not shown on the page, but is kept and shows again after an upgrade.

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`.

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.

Removes an announcement from the status page. Irreversible.

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. `is_disabled_by_plan: true` means the current plan has no webhooks: no events are delivered, but the URL, secret and subscriptions are kept and work again after an upgrade.

Takes no parameters.

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.

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.

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.

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.

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`: monitoring types (`service_alerts`, `ssl_alerts`, `domain_alerts`, `dns_alerts`, `blocklist_alerts`, `weekly_reports`) belong to a PROJECT and differ from project to project, the rest belong to the account. Without `project_id` the monitoring half is read from the oldest project. Webhooks have their own per-webhook `subscriptions` field and do not appear here.

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`, `updates`, `ideas`, `holiday_mode`) apply to the account as a whole. Returns the full updated list of rules.

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.

Takes no parameters.

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`.

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

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.