# Uptimepage Muse connector

From musedirectory.ai, the independent directory of Meta Muse connectors. Not affiliated with Meta.

## Uptimepage

Monitor website uptime, manage incidents, and publish status updates to keep customers informed.

- Record: https://musedirectory.ai/connector/uptimepage
- Category: Productivity
- Developer: Uptimepage (https://uptimepage.dev/mcp-server)
- Muse status: Extra setup. Not in Muse's Connectors list yet. Muse can still use it: its page gives you a request to paste into Muse.
- Health: Working, 976ms, checked 2026-09-28T09:16:03Z
- Endpoint: https://mcp.uptimepage.dev/mcp
- Auth: No account needed; Pricing: unknown
- Screening: Screened, no issues found (2026-09-24T23:15:49Z)
- Source: Found in the official MCP Registry (dev.uptimepage/uptimepage) https://registry.modelcontextprotocol.io/v0/servers?search=dev.uptimepage%2Fuptimepage

Connects to Uptimepage to create and manage uptime monitors for HTTP, TCP, DNS and other checks. Muse can run checks on demand, acknowledge incidents, post customer-facing status updates, and manage status pages showing your service health.

Example request: "Check if my website is down right now and post an update to my status page."

How to connect: Not in Muse's Connectors list yet, but Muse can still use it. Paste this into Muse: "Use Uptimepage to help me. It is a free service with an MCP server at https://mcp.uptimepage.dev/mcp. It does not need an API key. Ask me before you share anything with it." Muse asks before it shares anything with the app's site. Meta does not review apps used this way, so only use ones you trust. We tested this in the Muse app on September 24, 2026: Muse used an app's link directly this way and returned a live answer.

Tools:
- acknowledge_incident: 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
- add_status_page_components: 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. Monitor
- create_monitor: Create a monitor for an http, tcp, ping, dns, tls_cert, domain_expiry or heartbeat check. The check is run once before anything is saved and the result is shown to the user along with every setting it would apply; where the client can show a prompt, nothing is created unless they
- create_monitors: 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 it
- create_status_page: 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 
- get_flow_runs: 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: 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 
- get_incident: 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: 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_monitor: 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
- get_monitor_history: 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: 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: 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: One status page: name, public URL, enabled, and its components with each linked monitor's current state. Read-only.
- list_incidents: 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
- list_monitors: 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: 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
- list_regions: 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 i
- list_status_pages: List the org's status pages: slug, name, public URL, enabled. Cursor-paginated. Read-only.
- list_tags: 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: 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 h
- pause_monitor: Pause a monitor (stop its checks until resumed). Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only; idempotent.
- post_incident_update: 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.
- publish_incident: 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`
- resolve_incident: 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: 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: 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)
- unpublish_incident: 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_monitor: 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 
- update_status_page: Rename a status page, move it to a new slug, or publish and unpublish it. An omitted field is left alone. Changing the slug moves the public URL and breaks existing links. Not read-only; idempotent.
- update_status_page_component: 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.

Screening checks:
- MCP handshake: pass (Answered in 1387ms)
- Domain against threat feeds (Cloudflare security DNS): pass (mcp.uptimepage.dev, uptimepage.dev not flagged)
- Published packages against the OSV malicious-package database: n/a (No npm or PyPI package published)
- Hidden instructions or invisible characters in tool text: pass (31 tools read, nothing found)
- Inputs asking for passwords, card numbers or seed phrases: pass (None found)
- Domain and redirects: pass (Domain registered 131 days ago)
- AI review of purpose and tool behavior: pass (No concerns)