MCP server

Uptimepage Official

dev.uptimepage/uptimepage

Checked 25 Oct 2026, 20:29 UTC · Connected to it and listed its tools

Monitor uptime and incidents, run checks, and publish status updates from your Uptimepage org.

Website Source

At a glance

Type

MCP server

Publisher

uptimepage.dev (verified by the MCP Registry)

Status

Working at last check

Tools

39

Token cost

About 18,447 tokens per request

Sets up in

Claude Code, Claude Desktop, Codex, Gemini CLI, Cursor, VS Code, Antigravity, ChatGPT, OpenAI API, Grok

Last checked

25 Oct 2026, 20:29 UTC

Connect it to your agent

Add to CursorAdd to VS CodeVS Code Insiders

Opens the app, which shows the server and asks you to confirm. For other apps, copy the setup below.

Claude Code

claude mcp add --transport http uptimepage https://mcp.uptimepage.dev/mcp

Claude Desktop

Settings → Connectors → Add custom connector, and paste the URL.

Codex (config.toml)

[mcp_servers.uptimepage]
url = "https://mcp.uptimepage.dev/mcp"

Gemini CLI

{"mcpServers":{"uptimepage":{"httpUrl":"https://mcp.uptimepage.dev/mcp"}}}

Cursor

{"mcpServers":{"uptimepage":{"url":"https://mcp.uptimepage.dev/mcp"}}}

VS Code

{"servers":{"uptimepage":{"type":"http","url":"https://mcp.uptimepage.dev/mcp"}}}

Antigravity

agy mcp add uptimepage https://mcp.uptimepage.dev/mcp

ChatGPT

Settings → Apps & Connectors → Advanced settings: turn on Developer mode, then Create a connector and paste the URL. Which plans can do this varies.

OpenAI API (Responses tools)

{"type":"mcp","server_label":"uptimepage","server_url":"https://mcp.uptimepage.dev/mcp","require_approval":"always"}

Grok (xAI API tools)

{"type":"mcp","server_label":"uptimepage","server_url":"https://mcp.uptimepage.dev/mcp"}

Tools

• acknowledge_incident ~233 tokens
  Acknowledge an incident: take ownership and halt escalation. Internal/operational only — does NOT post anything to the public status page. Use post_incident_update for customer-facing updates. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-onl
• add_status_page_components ~566 tokens
  Add monitors to a status page as public components, in one confirmation where the client can show a prompt. Give each a public_name the page's readers will understand, since the monitor's own name is operator-facing, and a public_group to file related components together. Monitors already on the pag
• cancel_maintenance ~228 tokens
  Cancel a maintenance window that has not ended. It leaves the status pages, stops holding paging, and stays listed under past as a record; subscribers already told about it are not sent a cancellation. To stop a running window early and keep it as completed work, use update_maintenance with end_now
• create_maintenance ~515 tokens
  Schedule a maintenance window for planned work on some monitors. While it runs they show as under maintenance on every published status page that carries them, and unless suppress_alerts is false nobody is paged for them: checks keep running and incidents still open, so the history stays honest, and
• create_monitor ~3435 tokens
  Create a monitor for an http, tcp, ping, dns, tls_cert, domain_expiry, heartbeat or manual check. A manual monitor has nothing to probe; set its state afterwards with set_monitor_state. The check is run once before anything is saved and the result is shown to the user along with every setting it wou
• create_monitors ~3333 tokens
  Create several monitors at once, with one confirmation covering the batch where the client can show a prompt. Every check is run once first and all the results are shown together, so a misconfigured endpoint is visible before anything is saved. An item that fails validation or its trial run is repor
• create_status_page ~1097 tokens
  Create a status page. It is created unpublished unless you pass enabled, so its components can be curated before anyone can read it. The slug is the page's public address: it is first-come across the platform and moving it later breaks every existing link, so confirm it with the user rather than inv
• get_flow_runs ~196 tokens
  A browser flow monitor's recent runs over a window (1h/24h/7d/30d): every declared step with its outcome and duration, the step a failure stopped on, and the page the browser saw. Use this to answer why a login check failed. Read-only.
• get_flow_step_trend ~217 tokens
  How long each step of a browser flow monitor takes over a window (1h/24h/7d/30d), and how far it has moved: per step the earliest and latest mean duration, their ratio, and how many runs passed or failed it. Use this to spot a step drifting toward failure while the monitor still reports up. Read-onl
• get_incident ~155 tokens
  One incident: affected monitor, severity, open/resolved times, error sample, the full operator-update timeline, and the status pages an incident with no monitor is posted to. Read-only.
• get_incident_metrics ~165 tokens
  Incident metrics over a trailing window (default 30 days): MTTA/MTTR in seconds, total incidents, counts by severity and state, auto- vs human-resolved, and the noisiest monitors. Read-only.
• get_maintenance ~146 tokens
  One maintenance window: title, description, start and end, phase, the monitors it covers, and whether it holds their paging. Read-only.
• get_monitor ~262 tokens
  One monitor's full configuration — everything the check asserts (expected status, body match, headers, timeout, redirect and TLS policy), the regions it probes from, and how it alerts (failing checks before it pages, whether recovery is announced, the reminder interval, the multi-region quorum, and
• get_monitor_history ~263 tokens
  One monitor's history over a window (1h/24h/7d/30d): uptime, latency series, a per-region split of the same window, failures with error text, and incident windows. Pass `region` to narrow it to one probe region and tell a partial outage from a total one. Read-only.
• get_org_health ~69 tokens
  Org health summary: per-state monitor totals and the worst currently-failing monitors. The one-shot answer to 'what is broken right now?'. Read-only.
• get_org_usage ~104 tokens
  Which org this connector is bound to, and the account's resource usage against plan limits: monitors, status pages, members, components, and key policy values. Caps are pooled across every org the account owns, so the counts can exceed what this one org holds. Read-only.
• get_status_page ~134 tokens
  One status page: name, public URL, enabled, and its components with each linked monitor's current state. Read-only.
• list_incidents ~404 tokens
  List the org's incidents: incident id, affected monitor, severity, open/resolved times, and latest update phase. Defaults to currently-open ones; pass state="all" with an optional from/to window (default: last 30 days) for resolved history, and monitor_id to narrow to one monitor. Read-only.
• list_maintenance ~366 tokens
  List maintenance windows: title, start and end, phase (upcoming, active, completed or cancelled), the monitors each covers, and whether it holds their paging. status narrows to active, upcoming or past (ended or cancelled); the default is all, latest start first. Cursor-paginated. Read-only.
• list_monitors ~257 tokens
  List monitors with optional state/type/tag filters and cursor pagination. Each item carries its current state and last-checked time. Read-only.
• list_notification_channels ~214 tokens
  The org's notification channels: id, operator-set name, kind (email, slack, telegram, webhook, and so on), and whether the channel is enabled. Two flags say a channel is not working even where it reads as ready: awaiting_verification for an email address nobody confirmed, and not_delivering for an e
• list_regions ~172 tokens
  The fleet's probe regions: id, display name, city, country, continent, and whether each is on by default for a new monitor. Reports `max_regions` only when the plan reaches fewer regions than the catalog lists, so a set too large to be accepted is visible before it is sent. Use it to pass a valid `r
• list_status_page_viewers ~200 tokens
  List who signed in to a private status page: each viewer's address, first and last visit, saved passkeys, whether they subscribe by email, and whether they are blocked; and for the page password, which names nobody, the devices signed in with it, its last sign-in and the wrong tries in 24 hours. Add
• list_status_pages ~124 tokens
  List the org's status pages: slug, name, public URL, enabled. Cursor-paginated. Read-only.
• list_tags ~70 tokens
  Every tag in use across the org's monitors, most-used first, with how many monitors carry each. Pass one back as the `tag` filter to list_monitors. Read-only.
• list_variables ~140 tokens
  The org's reusable variables: key, and whether it is a secret. Values are never returned, and a secret's value is never even read. Write a variable into a monitor's header or body as `{{ key }}`, which is resolved when the check runs: this is how an authenticated check is built here, since pasting t
• pause_monitor ~173 tokens
  Pause a monitor (stop its checks until resumed). For planned work, create_maintenance holds paging instead while the checks keep running. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only; idempotent.
• post_incident_update ~262 tokens
  Post a public, customer-facing update to an incident's status-page timeline (phase + message). This is what your subscribers and status-page visitors see. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only.
• post_maintenance_update ~321 tokens
  Post an update to a maintenance window: say the work is running late, that it finished, or what changed. Works on an upcoming, running or completed window (a completed window is read-only otherwise, so this is how to add a closing note), not on a cancelled one. The update shows on the status pages t
• publish_incident Sends messages · ~405 tokens
  Publish an incident so it appears on every status page carrying the affected monitor, optionally seeding the public title and description. An incident with no monitor needs `status_page_ids` naming the pages to show it on; the list replaces its pages, so start from `get_incident`'s `status_page_ids`
• resolve_incident ~210 tokens
  Resolve an incident (mark the operational state resolved). Internal only — does not post to the public status page. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only.
• resume_monitor ~147 tokens
  Resume a paused monitor (restart its checks). Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only; idempotent.
• run_check_now ~183 tokens
  Run a check on a monitor immediately and record the result. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. A down result may fire the org's normal alerts. Heartbeat monitors cannot be probed (they wait for your systems to ping them). Not read-only.
• set_monitor_state ~526 tokens
  Set the state of a manual monitor: up, degraded or down. A manual monitor has no probe; its state is whatever an operator last set, for a service only people can judge, such as a SIP trunk, a carrier link or a partner's back office. Down or degraded opens an incident within about 30 seconds, which p
• unpublish_incident ~166 tokens
  Hide a published incident from the public status pages again. Its operator timeline is untouched. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only; idempotent.
• update_maintenance ~485 tokens
  Edit an upcoming or running maintenance window: its title, description, start, end, the monitors it covers (monitor_ids replaces the whole set) or whether it holds their paging. end_now ends a running window at once and keeps it as completed work. A completed or cancelled window is history and is re
• update_monitor ~1169 tokens
  Change how loudly a monitor is watched: check interval, alert confirmations, recovery notices, reminder interval, tags, group, the multi-region detection quorum, and which notification channels it alerts (channel_ids replaces the whole set, and needs the channels:read scope). It cannot change what t
• update_status_page ~1093 tokens
  Rename a status page, move it to a new slug, publish and unpublish it, or change who may open it. An omitted field is left alone. Changing the slug moves the public URL and breaks existing links. access replaces the page's access settings and list whole: protected true makes it private to the listed
• update_status_page_component ~242 tokens
  Change how one monitor is presented on a status page: its public name, description, group or position. An omitted field is left alone. Not read-only; idempotent.

Browse

• Website monitoring
• Domains and DNS
• Email
• To-do lists

Related MCP servers

• Better Stack MCP by usefulapi
  Read monitors, incidents, heartbeats, on-call and status pages; acknowledge or resolve incidents.
• Vantaj
  Vantaj uptime monitoring via MCP - manage monitors, heartbeats, incidents, and status pages.
• StatusPal MCP by usefulapi
  Read status-page status, services, incidents and metrics; create, update and publish incidents.
• API Status Check
  Live status probes plus published uptime and incident history for 280+ APIs and cloud services.
• OhSnap uptime monitoring
  Check if a website is down, add uptime monitors, read outage history and send test alerts.
• agentcheck
  Synthetic checks, nightly regression replay and model-drift alerts for AI agents
• Merlonix Monitoring
  Monitoring for agencies — uptime, SSL, DNS, blocklists, AI visibility, MCP health. 8 no-auth tools.
• UptyBots
  Uptime monitoring: create and manage HTTP, API, SSL, ping, port and domain checks

Badge for your README

[![AptLynx](https://aptlynx.net/badge/dev.uptimepage/uptimepage.svg)](https://aptlynx.net/servers/dev.uptimepage/uptimepage)

Listing text is written by the maker; AptLynx lists tools and does not vouch for them. Find another tool · Browse by topic · For agents