Uptimepage

dev.uptimepagePublished by uptimepage.devOfficial publisherv1.6.0Updated Oct 29, 2026

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

Overview

AI-generated overview

Uptimepage's hosted MCP server lets an assistant inspect one org's monitors, incidents and status pages, and take guarded actions like creating monitors or…

What you can do
  • Read health and configuration: org health, usage, monitors, monitor history and per-region latency, monitor groups, tags, probe regions, notification channels, variables
  • Read incidents and maintenance: incident lists and details, incident metrics (MTTA/MTTR), maintenance windows, browser flow runs and per-step trends
  • Create and change monitors: create one or many monitors, update, pause, resume, run a check now, set a manual monitor's state, edit monitor groups
  • Manage incidents: acknowledge, resolve, publish or unpublish an incident, post a customer-facing incident update
  • Manage maintenance windows: schedule, edit, cancel, end early, post an update
  • Manage status pages: create, rename…
When to use it
Useful when you want an assistant to answer questions about what is currently broken, why a check failed, or how a service has performed, and to make routine monitoring changes such as adding monitors, scheduling maintenance or narrating an incident without opening the dashboard.
Requirements
A remote Streamable HTTP endpoint; no local install. An Uptimepage account and an org-bound scoped token, pasted by hand or obtained through the one-click OAuth 2.1 connector. A token carries exactly one org and cannot switch; to work on another org, select it in the app and reconnect. Self-hosted instances must enable the MCP server explicitly.
Before you install
About half the tools write: they create, edit, pause, publish, resolve or cancel monitors, incidents, maintenance windows and status pages, and some post publicly visible updates to status pages and subscribers. Confirmation prompts appear only where the client can show one; otherwise actions run on the token's scopes alone. Never pass credentials as tool arguments; reference org variables instead. Running a check now can fire the org's real alerts. A new monitor pages nobody until a…

Installation

In SourceWeft

  1. Open Uptimepage in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/dev.uptimepage%2Fuptimepage/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config.

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

README

[A status page component with 90 days of uptime and the tooltip for one day.]

uptimepage

Uptime monitoring, status pages and on-call. Open source, free to start. Live in 5 minutes.

Monitor HTTP, TCP, ICMP ping, cron-job heartbeats, DNS, TLS-certificate and domain expiry, plus scripted browser login flows, from multiple regions — then turn green and red into a polished public status page your customers can subscribe to, and page whoever is on call through rotations and escalation policies. Drive it by click, REST API, or Terraform. Self-host the single binary or use the hosted service.

[Terraform Registry] [Artifact Hub] [Artifact Hub] [License: AGPL-3.0]

Try it free →  ·  Docs  ·  Self-host  ·  Terraform  ·  MCP

[uptimepage dashboard — uptime, response time, and per-monitor status]

Quick start

Hosted, no install:

  1. Sign up at uptimepage.dev with GitHub, Google or your email address — no card.
  2. Add a monitor: paste a URL, pick a check type and interval, save.
  3. Bind a notification channel (Slack, email, PagerDuty, …) so failures reach you.
  4. Turn on a public status page and share the link.

Prefer code? Drive the same account by REST API, Terraform, or MCP. Want to run it yourself? Go to Self-host.

Why uptimepage

Monitoring with a built-in status page isn't new — the bet here is doing it free, self-hostable, and fully as code:

  • Free hosted tier, no card — and AGPL if you'd rather run it yourself.
  • One self-contained binary — docker compose up and you're live, not a Kubernetes platform to operate.
  • Everything as code — REST API, scoped tokens, an official Terraform provider, and an MCP server your LLM can query.
  • Probes you own — run multi-region agents wherever your users are, on your own boxes.
  • Status page + incidents + on-call in one — components, subscribers, on-call rotations and escalation, and multi-channel paging that repeats until acknowledged, no second tool.
  • Core isn't paywalled — checks, status pages, subscribers, the API and every alert channel are in the free tier.

Who it's for

  • Founders / small SaaS — a professional status page in minutes, free, no self-host headache.
  • Platform / SRE leads — monitors as code, multi-region probes, incident paging to your on-call channels, without vendor sprawl.
  • Self-hosters — one binary plus two databases, no SaaS lock-in.

Live status

uptimepage monitors itself. These badges are served by the running app from a public status page — no third-party service, no cron job updating a JSON file.

[uptimepage status]

SurfaceHTTPDNSTLS certDomain
uptimepage.dev (website)[http][dns][tls][domain]
app.uptimepage.dev (dashboard)[http]
mcp.uptimepage.dev (MCP)[http]

Embed your own with the snippet in Settings → Pages → your page → Badge.

Features

ChecksHTTP, TCP, ICMP ping, heartbeat (inbound dead-man's-switch), DNS, TLS-cert expiry, domain expiry, browser login flow with per-step timings, manual (state set by an operator); a circuit breaker per monitor, designed for ~50k concurrent in-flight
Public status pageHTML + JSON + RSS, per-component opt-in, incident narration, maintenance windows, email + webhook subscribers
AlertingSlack, PagerDuty, Discord, Microsoft Teams, Google Chat, Mattermost, Telegram, WhatsApp, SMS, email, webhook, ntfy, Gotify, Pushover — per-org channels, sealed secrets, fire-once + recovery, repeat until acknowledged
IncidentsInternal incident state ⊥ public phase, acknowledge to silence paging, per-monitor reminder cadence
On-callLayered rotations (daily, weekly, custom) with weekly hours, calendar overrides, your shifts as an iCalendar feed, escalation policies that page channels and schedules level by level
Multi-regionRegional probe agents, per-region views, run your own agent anywhere
AutomationREST API, scoped API tokens, Terraform provider, MCP server for LLM clients
Built onRust 1.95 / Tokio / Axum, Postgres + ClickHouse, one ~23 MB self-contained binary

Live service: https://uptimepage.dev — hosted, free, sign in with GitHub, Google or your email address. Full docs: https://uptimepage.dev/docs

Check types

TypePurposeDefault intervalFloor
httprequest a URL, match status / body / latency60 smax(plan_min, 10 s)
tcpopen a TCP socket within a timeout60 smax(plan_min, 10 s)
pingICMP echo request, fail on a missing reply60 smax(plan_min, 10 s)
heartbeatyour job pings a URL; a missing ping past period + grace opens an incident60 smax(plan_min, 60 s)
dnsresolve a record, optionally match a value60 smax(plan_min, 10 s)
tls_certopen TLS, parse leaf cert, alert before notAfter86 400 s (daily)max(plan_min, 3600 s)
domain_expiryquery RDAP, alert before the domain's expiration event86 400 s (daily)max(plan_min, 43 200 s)
flowdrive a headless browser through login / transaction steps, assert the result300 smax(plan_min, 300 s)
manualno probe; an operator sets up, degraded or down and it restates that state60 sexactly 60 s

tls_cert and domain_expiry use warn_days / critical_days thresholds and surface days_remaining plus registrar / cert subject in the result payload. Their floors are 1 hour for tls_cert and 12 hours for domain_expiry, regardless of plan — these probes track values that change on a scale of days, not minutes, and RDAP rate-limits by source address. flow runs a real browser, so it only executes where a browser engine is available (its regions clamp to the flow-capable set) and the number of flow monitors is capped per plan; put credentials in an org secret and reference them as {{name}}. Every flow run is kept with each step's outcome and duration, and the monitor page charts each step on its own scale, so a wait drifting from 200 ms to four seconds shows up long before the journey fails. A self-hosted install starts with that cap at 0; docs/monitor-types.md covers turning it on. See docs/api.md for the full payload shapes.

Public status page

A customer-facing /status page (HTML + JSON + RSS 2.0) is built into the binary. Per-target opt-in via public_status; the page's routes carry no auth extractor, so it is public wherever the binary runs, with a per-IP rate limit at the edge, caches for 10 s in-process, and degrades gracefully if ClickHouse is unreachable. Operators narrate incidents (PATCH /api/v1/incidents/{id}, POST /api/v1/incidents/{id}/updates) and schedule maintenance windows (POST /api/v1/maintenance). Visitors subscribe for email or webhook updates. See docs/public-status.md.

Alerting

Notification channels are per-org resources (Slack incoming webhook, generic HTTP webhook, Telegram bot, SMS gateway, …) created via /api/v1/notification-channels. Transport secrets are sealed at rest and never echoed back.

A target opts in by binding one or more channels in its alerts array:

jsonc
"alerts": [  { "channel_id": "0192…", "after_failures": 3 },  { "channel_id": "0193…", "after_failures": 6, "notify_recovery": false }]

Fire-once + recovery semantics. Channels are tenant-isolated — a target can only bind a channel its own org owns. See docs/api.md for the full contract.

Multi-region

Run probe agents in the regions your users live in; the control plane assigns checks per region and the dashboard and status page can be viewed per-region. Bring your own agent anywhere — a single binary with an org-scoped token. See docs/multi-region.md.

Terraform

Manage targets and notification channels as code with the official provider uptimepage/uptimepage (source):

hcl
terraform {  required_providers {    uptimepage = {      source = "uptimepage/uptimepage"    }  }}
provider "uptimepage" {  token = var.uptimepage_token # or set UPTIMEPAGE_TOKEN  org   = "your-org-slug"      # required for managed resources; or UPTIMEPAGE_ORG  # endpoint defaults to https://app.uptimepage.dev; set it for a self-hosted instance}
resource "uptimepage_target" "api" {  name     = "api prod"  interval = 60  check = {    type = "http"    http = {      url             = "https://example.com/healthz"      expected_status = { kind = "exact", exact = 200 }    }  }}

MCP server

An MCP server lets an LLM client (the claude.ai connector, Claude Desktop, an IDE) answer questions about one org's monitors and take a few guarded actions, over Streamable HTTP at /mcp. Nineteen read-only tools plus nineteen write tools (each scope-gated and audited, and confirmed per action where the client can show a prompt). Auth is an org-bound scoped token — paste one by hand, or use the one-click OAuth 2.1 connector. Off by default; enable with UPTIMEPAGE_MCP_ENABLED=true (+ MCP_OAUTH_ENABLED for the connector). See docs/mcp.md.

Self-host

I want toGo to
Try it with one commandDocker
Run it for real, with TLS and authProduction deployment
Build the image myself (ARM host, or code changes)Build from source
Skip Docker and run the binaryRun without Docker

Docker (recommended)

Three steps. No Rust toolchain and no compile step.

1. Start it

bash
docker compose up -d

Pulls ghcr.io/uptimepage/uptimepage:latest and starts Postgres 18, ClickHouse 26.3, and the monitor. Both databases run their own migrations at startup, so there is nothing to wire up.

2. Create your account

bash
docker compose exec uptimepage uptimepage bootstrap-owner --email [email protected]

Prints a one-time sign-in link, a full-access API token, and your org slug. These appear once, so copy them before closing the terminal.

3. Sign in and add a monitor

Open the link from step 2. That drops you into the dashboard at http://localhost:8080, where you can add your first monitor.

To stop: docker compose down, or docker compose down -v to delete the data too.

This stack has no TLS and no auth in front of it, and it publishes the database ports. Great for trying it out, not safe on the open internet. To run it for real, see Production deployment.

Options

Pin a version. Set UPTIMEPAGE_IMAGE=ghcr.io/uptimepage/uptimepage:1.6.0 to stay on a release instead of latest. Release tags carry no v prefix, though the git tag they are built from does.

On an ARM host? Release tags are linux/amd64 and linux/arm64. latest, which tracks the newest commit on main, is amd64 only, so pin a release on ARM.

ClickHouse system logs are off. Stock ClickHouse keeps two dozen system.*_log tables that grow without bound and use CPU at idle. Uptimepage reads none of them, so config/clickhouse-quiet.xml turns them all off; to get one back for debugging, delete its line there and run docker compose up -d --force-recreate clickhouse (a plain restart can keep reading the old file). A stack started before this setting existed keeps its old tables: run docker compose up -d first so ClickHouse restarts with the setting, then list them with SELECT name, formatReadableSize(total_bytes) FROM system.tables WHERE database = 'system' AND name LIKE '%\_log%' and remove each with DROP TABLE system.<name>.

Signing in later. The bootstrap link works once. For repeat sign-in, and to invite a team, set up OAuth with GitHub, GitLab, Google or Microsoft, or an email provider for magic links ([auth.github], [auth.gitlab], [auth.google], [auth.microsoft], [email] in config/default.toml, or the matching env vars). See docs/authentication.md.

Packaging this for an app store? Step 2 needs a terminal. Set UPTIMEPAGE_BOOTSTRAP__EMAIL instead and the first boot seeds that owner and logs a sign-in link, no shell required. See First-run owner.

Prefer the API to the dashboard?

Use the token and org slug from step 2. Create a monitor:

bash
curl -X POST http://127.0.0.1:8080/api/v1/targets \  -H 'authorization: Bearer <token>' \  -H 'x-uptimepage-org: <org-slug>' \  -H 'content-type: application/json' \  -d '{    "name": "example",    "check": {      "type": "http",      "url": "https://example.com/",      "method": "GET",      "timeout": 10000,      "follow_redirects": false,      "max_redirects": 0,      "expected_status": { "kind": "exact", "value": 200 },      "headers": {},      "verify_tls": true    },    "interval": 180,    "enabled": true,    "tags": []  }'

interval is in seconds and has to meet the plan minimum, which is 180 on the free plan the bootstrap-owner step above starts you on. Anything lower returns 422 MIN_CHECK_INTERVAL. Seeding the owner at first boot instead (see First-run owner) places that org on quotas.default_plan, which defaults to team and a 30-second floor. An org created later through signup lands on founding while that tier is open, where the floor is 60 seconds.

Read uptime and scrape metrics:

bash
curl -H 'authorization: Bearer <token>' -H 'x-uptimepage-org: <org-slug>' \  http://127.0.0.1:8080/api/v1/targets/<id>/uptimecurl http://127.0.0.1:9090/metrics

Production deployment

Anything reachable from the internet should run this stack, not the one above. It adds a Caddy edge with automatic TLS, internal-only Postgres and ClickHouse, per-IP rate limits, and blue/green restarts. The operator host is guarded by the app's own sign-in, not by an edge credential. It pulls the same published image. Setup runbook is in deployment/README.md, with the architecture in docs/deployment.md.

Kubernetes

bash
kubectl create namespace uptimepagekubectl -n uptimepage create secret generic uptimepage \  --from-literal=fingerprint-salt="$(openssl rand -base64 32)" \  --from-literal=credentials-kek-base64="$(openssl rand -base64 32)" \  --from-literal=postgres-url='postgres://uptimepage:[email protected]:5432/uptimepage?sslmode=require' \  --from-literal=clickhouse-password='pw'
helm install uptimepage oci://ghcr.io/uptimepage/charts/uptimepage \  --namespace uptimepage \  --set domain=status.example.com \  --set clickhouse.url=https://ch.internal:8443 \  --set secrets.existingSecret=uptimepage \  --set postgresql.existingSecret=uptimepage \  --set clickhouse.existingSecret=uptimepage

Bring your own Postgres 18 and ClickHouse; the chart ships neither. A second chart, uptimepage-agent, runs a probe on its own in another region or inside a private network, against this or the hosted service. Details in docs/kubernetes.md and charts/.

Build from source

Published images are linux/amd64. Build from this checkout when you are on an ARM host (Apple silicon, Ampere), or when you are changing the code:

bash
docker compose -f docker-compose.yml -f compose.build.yml up -d --build

Same stack and the same three steps as Docker, only the image origin differs. Note that your local build then owns that image tag, so run docker compose pull when you want the published image back.

Run without Docker

bash
cargo build --release./target/release/uptimepage

Requires Postgres and ClickHouse reachable at the URLs in config/default.toml, plus a non-empty fingerprint salt (the app refuses to boot without one):

bash
export UPTIMEPAGE_AUTH__FINGERPRINT_SALT=$(openssl rand -base64 32)

To run against the compose stack without rebuilding the container:

bash
docker compose up -d postgres clickhousecargo run --release

Docs

Hosted: https://uptimepage.dev/docs

Sources under docs/ — readable directly on GitHub too:

FileCovers
docs/architecture.mdgoals, module layout, data flow, key design choices, concurrency model
docs/api.mdREST endpoints, check-spec payload shapes, result + uptime queries
docs/public-status.mdoperator guide to the public /status page: components, incidents, maintenance
docs/authentication.mdsign-in, sessions, scoped API tokens, org binding
docs/multi-region.mdregional probe agents, the operator surface, running an agent, per-region views
docs/mcp.mdMCP server for LLM clients: tools, scopes, OAuth connector, enabling, examples
docs/configuration.mddefault.toml reference, env override scheme, tuning notes
docs/metrics.mdPrometheus series (incl. connect / TLS / pool gauges), OpenTelemetry tracing
docs/deployment.mdDocker, bind addresses, migrations, sizing, graceful shutdown
docs/development.mdlocal dev workflow, the web UI (stack, routes, adding a page, tests), faster builds
docs/loadtest.mdbin/loadtest envs, macOS gotchas, HTTP/1 vs h2c trade-off, Linux container path
docs/benchmarks.mdCriterion micro-benchmarks, single-core throughput, profile breakdown
docs/troubleshooting.mdcommon failures and how to read them off metrics

Web UI

The single binary serves both the /api/v1/* JSON surface and a server-rendered HTML UI at / — askama compile-time templates, HTMX for partial swaps and JSON forms (no SPA framework), Tailwind CSS 4, and lazy-loaded ECharts. Every UI mutation hits an existing /api/v1/* endpoint, so the API stays the single source of truth. Stack, routes, the add-a-page recipe, and UI tests are in docs/development.md.

Legal

Policies belong to whoever runs the instance. Point the [legal] URLs at your own terms, privacy policy and the rest: the app links each one you set, shows terms and privacy at signup and records their versions on new accounts, and links nothing you leave empty. See docs/configuration.md. GDPR self-service (data export, account deletion, recovery) lives under /settings/account.

License

uptimepage is licensed under AGPL-3.0. See LICENSING.md for what this means in practice. The name and logo are trademarks; see TRADEMARKS.md before you run a public service or a fork.

If you'd like to contribute, see CONTRIBUTING.md. For security disclosures, see SECURITY.md.

Source: README.md at commit c5e7b33

Tools

41

acknowledge_incident

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 scope. Not read-only.

Parametersidrequirednote

add_status_page_components

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. Monitors already on the page are reported as such rather than duplicated. detail_link_enabled publishes a per-monitor detail view that shows the monitor's real name and address, not public_name. groups adds monitor groups as live sections: a heading with the members' combined state, every member as its own row, and members that join or leave the group joining or leaving the page; members past the plan's public component limit stay off. Not read-only.

Parametersslugrequiredgroupscomponents

cancel_maintenance

Cancel maintenance

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 instead. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only.

Parametersidrequired

create_maintenance

Schedule maintenance

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 an incident still open when the window ends pages then. Prefer this over pause_monitor for planned work. Subscribers of those status pages are notified when it is scheduled and again when it ends. Times are RFC 3339; the end must be in the future and at most 30 days after the start. Shows the window, its monitors, whether paging is held and where it is announced, where the client can show a prompt; otherwise runs on the token's scope. Not read-only.

Parameterstitlerequiredends_atrequiredstarts_atrequireddescriptionmonitor_idsrequiredsuppress_alerts

create_monitor

Create monitor

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 would apply; where the client can show a prompt, nothing is created unless they approve; otherwise the monitor is created on the token's scope and the trial result comes back with it. Bind it to alerts as you create it: pass channel_ids from list_notification_channels (this needs the channels:read scope), and if the org has no channel yet, say so rather than leaving a monitor that pages nobody. Leave regions unset unless the user named where they want the check to run from — omitted, it probes from the operator's default set, which is already the intended coverage; naming more regions than the plan allows is refused outright. Request headers and a request body can be set, but a credential must be referenced rather than pasted: write `Bearer {{ my_key }}` and call list_variables for the keys this org has. A URL carrying a username or password is refused, and browser flows cannot be created here — add those in the app. Not read-only.

Parametersnamerequiredtagscheckrequiredregionsgroup_namechannel_idsinterval_secsregion_policynotify_recoveryalert_confirmationsrecovery_period_secsrenotify_interval_secs

create_monitors

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 its trial run is reported in the results and the rest are still created. Prefer this over repeated create_monitor calls whenever the user names more than one thing to watch: it costs them one prompt instead of many. Same per-monitor fields and same limits as create_monitor. Not read-only.

Parametersmonitorsrequired

create_status_page

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 user rather than inventing one. Pass access with protected true to make it private: only the listed domains and addresses can open it, after signing in with a code sent to their email (Team plan). Add monitors to it with add_status_page_components. Not read-only.

Parametersnamerequiredslugrequiredaccessenabled

get_flow_runs

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

Parametersidrequiredwindowrequired

get_flow_step_trend

Browser 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 reports up. Read-only.

Parametersidrequiredwindowrequired

get_incident

Incident details

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.

Parametersidrequired

get_incident_metrics

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.

Parameterswindow_days

get_maintenance

Maintenance window details

One maintenance window: title, description, start and end, phase, the monitors it covers, and whether it holds their paging. Read-only.

Parametersidrequired

get_monitor

Monitor details

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 the ids of the channels it notifies) — with its current state, last error, and 24h/30d uptime. Every field update_monitor can change is readable here, in the shape that tool takes. Read this before judging whether a response should have passed, or before changing a monitor. Credentials are withheld. Read-only.

Parametersidrequired

get_monitor_history

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.

Parametersidrequiredregionwindowrequired

get_org_health

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.

Takes no parameters.

get_org_usage

Usage against plan

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.

Takes no parameters.

get_status_page

Status page details

One status page: name, public URL, enabled, its components with each linked monitor's current state, and the monitor groups it shows as sections with their members. Read-only.

Parametersslugrequired

list_incidents

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

Parameterstofromstatecursormonitor_id

list_maintenance

List maintenance windows

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.

Parameterscursorstatus

list_monitor_groups

List monitor groups

The org's monitor groups, empty ones included: name, whether the group alerts as one (a member's failure opens one group incident that pages the group's channels, and the members' own stay quiet), member count, the group incident open now, its channels, reminder interval, whether another member going down sends a message, and tags. Read-only.

Takes no parameters.

list_monitors

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.

Parameterstagtypestatecursor

list_notification_channels

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_delivering for an enabled channel whose recent alerts all failed to arrive. auto_bind_tags is the channel's tag rule: it also pages any monitor carrying one of those tags, so a monitor with no binding can still be covered. Channel settings are withheld, since they hold webhook URLs and bot tokens. Channels are created in the Uptimepage app, not here. Read-only.

Takes no parameters.

list_regions

List probe 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 it to pass a valid `region` to get_monitor_history, and to read where a check would run from. This is a catalog, not a menu to fill: leave `create_monitor.regions` unset unless the user named the places they want covered. Read-only.

Takes no parameters.

list_status_page_viewers

List status page viewers

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. Addresses are customer data. Read-only.

Parametersslugrequired

list_status_pages

List status pages

List the org's status pages: slug, name, public URL, enabled. Cursor-paginated. Read-only.

Parameterscursor

list_tags

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.

Takes no parameters.

list_variables

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 here, since pasting the credential itself is refused. Variables are created and edited in the app, not here. Read-only.

Takes no parameters.

pause_monitor

Pause monitor

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.

Parametersidrequired

post_incident_update

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.

Parametersidrequiredphasemessagerequired

post_maintenance_update

Post maintenance update

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 that show the window and goes to their email and webhook subscribers; it cannot be edited or removed. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only.

Parametersidrequiredmessagerequired

publish_incident

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`'s `status_page_ids`. Status-page subscribers may be notified. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only; idempotent.

Parametersidrequiredpublic_titlestatus_page_idspublic_description

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

Parametersidrequirednote

resume_monitor

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.

Parametersidrequired

run_check_now

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). Not read-only.

Parametersidrequired

set_monitor_state

Set manual monitor state

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 pages the monitor's channels unless a maintenance window holds it, and shows on its status pages as a major outage or degraded performance; up closes the incident. A paused monitor, or one the plan no longer covers, keeps the state and acts on it once it runs again. The note becomes the incident's cause, so make it a reason a responder can act on. Refused for any other kind of monitor. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only; idempotent.

Parametersidrequirednotestaterequired

unpublish_incident

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.

Parametersidrequired

update_maintenance

Edit maintenance

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 refused. Shows the old and new value of every field before it runs, where the client can show a prompt; otherwise runs on the token's scope. Not read-only.

Parametersidrequiredtitleend_nowends_atstarts_atdescriptionmonitor_idssuppress_alerts

update_monitor

Retune 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 cannot change what the check watches — name, address, assertions, expected status, headers, body, probe regions and owner are refused. A monitor managed by Terraform is refused outright. Shows the old and new value of every field before it runs, where the client can show a prompt; otherwise runs on the token's scope. Not read-only.

Parametersidrequiredtagsgroup_namechannel_idsinterval_secsregion_policynotify_recoveryalert_confirmationsrecovery_period_secsrenotify_interval_secs

update_monitor_group

Change monitor group

Change a monitor group: its name, whether it alerts as one (a member's failure opens one group incident that pages the group's channels, and the members' own stay quiet), which notification channels the group incident alerts (channel_ids replaces the whole set, and needs the channels:read scope), the reminder interval, and whether another member going down sends a message. Turning alert as one on or off changes only failures that start afterwards. A group managed by Terraform is refused outright. Shows the old and new value of every field before it runs, where the client can show a prompt; otherwise runs on the token's scope. Not read-only.

Parametersidrequirednamealert_againchannel_idsalert_as_onerenotify_interval_secs

update_status_page

Update status page

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 domains and addresses (Team plan), and removes subscribers the list does not cover; protected false makes it public again and keeps the list. Not read-only; idempotent.

Parametersnameslugrequiredaccessenablednew_slug

update_status_page_component

Update status page component

Change how one monitor is presented on a status page: its public name, description, group or position; or, with section_id, a group section's heading. An omitted field is left alone. A section member's heading is its section's, so its public_group does nothing. Not read-only; idempotent.

Parametersslugrequiredheadingmonitor_idsection_idsort_orderpublic_namepublic_grouppublic_description

Version history

2
  1. v1.6.0LatestOct 29, 2026
  2. v1.0.0Sep 16, 2026

Score

100% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts