Menu
Create and publish a public status page from monitors, groups, or tags, and manage announcements (incident, maintenance, info notices) on it.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Modify an existing UptimeRobot monitor — rename, change URL/interval, swap alert contacts, retag, tweak HTTP/keyword/API/heartbeat settings, and toggle SSL or domain reminders.
Choose between monitor groups and tags for organizing monitors — group membership is opaque and write-only over MCP, so tags are usually the better default.
Pause (or resume) many UptimeRobot monitors at once — by tag, search term, or state — around a deployment or maintenance window.
End-to-end incident workflow — find what's down, diagnose it, pause flapping monitors, and verify recovery.
Schedule one-off or recurring maintenance windows that suppress alerts for planned downtime, as an alternative to bulk-pause.
Create a free UptimeRobot HTTPS uptime monitor for someone using ONLY their email, no UptimeRobot account, no API key, and no MCP/OAuth. The agent calls an unauthenticated proof-of-work-gated API; the owner confirms with one click in an activation email. Use when a user wants monitoring but is not signed in to UptimeRobot and has no API key, the zero-setup path.
| name | status-pages |
| description | Create and publish a public status page from monitors, groups, or tags, and manage announcements (incident, maintenance, info notices) on it. |
| tags | ["status-page","psp","announcements","public","uptimerobot"] |
Preflight — read first. If you cannot see any
uptimerobot:*MCP tools in your tool list, invoke theuptimerobot:setupskill before doing anything else. Do not tell the user the MCP is misconfigured —setup's Step 0 detects the common case (server connected, tools loaded after session start) and resolves it without re-keying.
Use this when the user says "set up a status page", "publish uptime for customers", "post a maintenance notice on the status page", or "let people know we're investigating".
Two linked resources: the page itself (create/update/get/list-psp) and announcements posted to it (create/update/get/list/pin/unpin-psp-announcement, requires the psp-subscribers plan feature).
create-psp accepts three mutually-exclusive-in-practice ways to pick monitors, plus a fourth override:
| Field | Behavior |
|---|---|
monitorIds | Explicit list. Ignored if autoAddMonitors: true. The only field that populates the response's monitorIds array. |
monitorGroupIds | Resolves group membership into monitorsCount correctly (verified) — see manage-monitor-groups. |
tagIds | Resolves tagged monitors into monitorsCount correctly (verified). |
autoAddMonitors: true | Every current monitor on the account (monitorsCount matches the account's full monitor total). Per the tool description it also auto-adds future monitors, though that part isn't independently confirmed. Ignores monitorIds. |
monitorGroupIds/tagIds resolve into monitorsCount but the monitorIds array in the response stays empty. Don't read an empty monitorIds on a group/tag-scoped page as "no monitors are showing"; check monitorsCount instead. autoAddMonitors: true is stranger still: monitorIds comes back as [0] (a sentinel, not the real list and not []) — don't read anything into that value on an auto-add page either.
Side effect worth knowing about, not a recommended workflow: monitorsCount reflects real group membership, so a page scoped by monitorGroupIds: [<id>] indirectly reveals how many monitors are in a group — manage-monitor-groups has no direct read for this. But don't reach for this casually: since create-psp ignores status: PAUSED (below), the page is genuinely public the moment it's created, exposing real monitor topology/counts. Get explicit user confirmation before creating a page for this purpose, and immediately pause it afterward — don't do this autonomously as a routine check.
Ask before using autoAddMonitors: true — it's convenient but means internal/staging monitors show up on a public page unless the user is deliberate about it, and it touches every monitor on the account.
{ "friendlyName": "Acme API Status", "monitorIds": [800111, 800222], "status": "PAUSED" }
create-psp ignores status: PAUSED. The page is created ENABLED (public) regardless of what you pass. If the user wants to review before going live, you must immediately follow up with a second call:
{ "pspId": 900123, "status": "PAUSED" }
(via update-psp — that one does respect status.) Confirm with get-psp that it actually landed as PAUSED before telling the user the page is a private draft. Skipping this means a half-configured page (wrong monitors, no password) is public from the moment it's created.
Things MCP cannot do — tell the user to use the dashboard instead:
customDomain at UptimeRobot — the field just registers the domain; the user still needs to create the CNAME record with their DNS provider.Announcement status has four states and only pspId is schema-required. The blank defaults are not safe: omitting title/content leaves them null (a blank notice), and omitting status/startDate doesn't fall back to Offline (draft) — it defaults to Pending with startDate set to the current time, which will auto-publish blank (see below). Always set title, content, type, and status explicitly:
| Status | Meaning |
|---|---|
Offline | Draft, not visible |
Pending | Scheduled — auto-publishes once startDate passes |
Published | Live now |
Archived | Was live, now hidden but kept for history |
Pending → Published is asynchronous, not instant. A background job publishes Pending announcements once startDate arrives, but it doesn't run the moment startDate passes — expect a short delay (on the order of a minute) before the status flips. Don't assume "still shows Pending when I just checked" means it's stuck, and don't assume you must manually flip it to Published at the exact scheduled time. If the user needs it live immediately, set status: Published directly rather than relying on the delay.
{
"pspId": 900123,
"title": "Investigating elevated error rates",
"content": "We're seeing increased 5xx errors on the API. Investigating.",
"type": "Issue",
"status": "Published",
"startDate": "2026-07-02T14:05:00Z"
}
type is Info, Maintenance, or Issue — pick Issue for incident updates, Maintenance for planned work (cross-reference maintenance-windows if the user is also scheduling one), Info for everything else.
creationDate isn't stable. It changes on every update-psp-announcement call, not just at creation (behaves like "last modified" despite the name). Don't use it to report when an announcement was originally posted if it's been edited since — capture the timestamp yourself at creation time if the user needs an accurate history.
Pin the active incident announcement so it's the first thing visitors see:
{ "pspId": 900123, "announcementId": 5001 }
(via pin-psp-announcement). Unpin and set status: Archived once resolved — don't just leave it pinned and stale.
User: "We're down, post something on the status page and let me know when it's resolved so I can update it."
list-psps (or ask) to find the right pspId.create-psp-announcement with type: Issue, status: Published, describing the incident.pin-psp-announcement so it's visible at the top.update-psp-announcement with status: Archived (or edit the content to say "Resolved" and leave it briefly before archiving).unpin-psp-announcement.create-psp with status: PAUSED produces a draft — it doesn't; the page goes live immediately and needs a follow-up update-psp call to actually unpublish.status: ENABLED) before the user has reviewed which monitors are included — internal monitors leak onto a public page.autoAddMonitors: true without asking — it includes every current monitor on the account; confirm before using since it also touches every internal/staging monitor.pspId set expecting a safe draft — it saves as Pending with startDate: now, which will auto-publish blank once the background job runs (not instantly, but not a stable draft either). Always fill title + content + type + status.Pending announcement checked moments after creation is stuck/broken because it hasn't auto-published yet — the transition job runs asynchronously; give it time before concluding it's not working.Published — archive and unpin once it's over.manage-monitor-groups — groups/tags feeding monitorGroupIds / tagIds.maintenance-windows — pair a Maintenance-type announcement with an actual suppression window.incident-response — the incident this announcement is usually about.errors — -28002 subscription_limit_exceeded when the plan lacks psp-subscribers.