Openuptime

app.openuptimePublished by openuptime.appOfficial publisherv1.0.0Updated Oct 24, 2026

Manage uptime monitors, incidents and status pages from any MCP client.

VerifiedStreamable HTTPWeb executableCloud & InfrastructureSecurity & Monitoring

Overview

AI-generated overview

OpenUptime's hosted MCP endpoint lets an AI assistant manage uptime monitors, incidents and status pages from any MCP client.

What you can do
  • Manage uptime monitors: HTTP/HTTPS with keyword matching, TCP, DNS, WebSocket, heartbeat, database and RPC node checks
  • Handle incidents: acknowledgement, assignment and postmortems, plus maintenance windows
  • Maintain public status pages, including subscriptions, badges and embeds
  • Work with workspaces, projects and roles for team access
  • Use the same tools against the hosted service or a self-hosted instance at its own /api/mcp path
When to use it
Useful when you already run uptime monitoring in OpenUptime and want an assistant to create or adjust monitors, triage incidents or update status pages without opening the dashboard. Also fits teams that self-host OpenUptime and want agent access to their own instance.
Requirements
A remote Streamable HTTP endpoint at the provider's /api/mcp path (or your own self-hosted host). OAuth authorization is required; the README also mentions API keys as an alternative. A hosted account, or a self-hosted deployment with Postgres and its own secrets.
Before you install
The tools can change monitoring state: creating or editing monitors, acknowledging and assigning incidents, and altering public status pages, so assistant actions are visible to visitors and on-call staff. The hosted service is plan-based and paid plans start at $5/month. Self-hosting requires secrets such as BETTER_AUTH_SECRET and CRON_SECRET, and hosted data lives in the provider's database.

Installation

In SourceWeft

  1. Open Openuptime in the dashboard and add it to a workspace.
  2. Connect the required credentials. They are stored privately and never shown on public pages.
  3. 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/app.openuptime%2Fmcp/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. The client completes OAuth sign-in on first connect.

{
  "mcpServers": {
    "openuptime": {
      "type": "http",
      "url": "https://openuptime.app/api/mcp"
    }
  }
}

README

[OpenUptime]

OpenUptime

Open-source uptime monitoring and status pages. Runs on Cloudflare Workers with Postgres, or in one Docker container.

Hosted version · Docs · Reference · MIT license

Features

Monitoring

  • HTTP / HTTPS with keyword matching and slow-response alerts
  • TCP, DNS and WebSocket
  • Heartbeat (push) monitors for cron jobs and background workers
  • PostgreSQL, MySQL and Redis
  • Domain expiry
  • EVM and Solana RPC node health
  • MCP server checks
  • Multi-region checks, with your own probes
  • Monitor dependencies, so a downstream outage doesn't page you twice

Incidents and status pages

  • Incidents with acknowledgement, assignment and postmortems
  • Maintenance windows, one-off or recurring
  • Public status pages
  • Email and RSS subscriptions for status page visitors
  • Status badges and embeds for your site or README

Alerts

  • Slack, Discord, Microsoft Teams, Telegram, Lark / Feishu and ntfy
  • PagerDuty, webhooks and email
  • Push notifications to the iOS app
  • Repeat reminders and escalation

Teams and automation

  • Workspaces, projects and roles
  • GitHub sign-in and two-factor authentication
  • REST API with API keys
  • MCP server so your AI agent can manage monitors, incidents and status pages
  • JSON import / export
PartStack
apps/apiHono, better-auth, Cloudflare Worker (cron + queue consumer)
apps/webAstro (static pages, SSR for status pages) + React islands
packages/repoStorage interface (Repo) and entity types
packages/db-pgPostgres implementation of Repo: Drizzle schema, migrations

Deploy to Cloudflare

The site is two Workers on one domain:

WorkerServesAlso does
openuptime-apiyour-domain/api/* (a Worker route on your zone)minute cron, queue consumer that runs the checks
openuptime-webeverything else on your-domain (a Worker custom domain)status pages (SSR); reaches the API through a service binding

Keeping the API under /api/* of the same domain means session cookies stay same-origin. You need no separate API hostname.

Before you start

  • A Cloudflare account and a domain whose DNS is on Cloudflare (the zone).
  • A Postgres database reachable from the internet (Neon, Supabase, RDS, your own). Workers connect through Hyperdrive.
  • Node.js 22+ and pnpm (corepack enable provides the pinned version).
  • Workers Paid plan for the Queue (default). On the Free plan, run in inline mode instead: see Reference.

1. Get the code and sign in

bash
git clone https://github.com/becoolme/openuptime.git && cd openuptimepnpm installcd apps/api && npx wrangler login

All npx wrangler … commands below run in apps/api unless noted.

2. Create the Queue and Hyperdrive

bash
npx wrangler queues create openuptime-checksnpx wrangler hyperdrive create openuptime-prod --connection-string="postgres://user:pass@host:5432/db"

The second command prints an id. In apps/api/wrangler.jsonc uncomment the hyperdrive line and paste it:

jsonc
"hyperdrive": [{ "binding": "HYPERDRIVE", "id": "<id printed above>" }],

The commented placement line is optional (it runs the Worker next to your database host); leave it commented unless you want that.

3. Create the schema

From the repository root:

bash
DATABASE_URL="postgres://user:pass@host:5432/db" pnpm db:migrate

It only applies what is new, so run it again after every upgrade. It never issues CREATE SCHEMA, so a role without database-level CREATE works too.

4. Point the config at your domain

Edit two files. In both, replace status.example.com with your own domain.

apps/api/wrangler.jsonc, where zone_name is the zone (the apex domain) even when you serve from a subdomain. Uncomment routes and set:

jsonc
"routes": [{ "pattern": "status.example.com/api/*", "zone_name": "example.com" }],"vars": {  "BETTER_AUTH_URL": "https://status.example.com",   // public origin: cookies, OAuth, email links  "WEB_ORIGIN": "https://status.example.com",        // same value  "EMAIL_FROM": "[email protected]"                 // sender address; optional, see below}

Email is optional: without it invitations and alerts are written to the Worker log. To send it, onboard your domain under Email Sending in the Cloudflare dashboard first (see Reference).

apps/web/wrangler.jsonc:

jsonc
"routes": [{ "pattern": "status.example.com", "custom_domain": true }],"vars": { "PRODUCT_URL": "https://status.example.com" }   // target of the "Powered by" link on status pages

The custom domain creates its DNS record and certificate for you; the hostname must not already have a DNS record pointing elsewhere.

No domain on Cloudflare? Leave routes out of both files and set BETTER_AUTH_URL and WEB_ORIGIN to the web Worker's https://openuptime-web.<your-subdomain>.workers.dev address. The web Worker then forwards /api/* to the API Worker through the service binding, so cookies stay same-origin.

5. Set the secrets

bash
npx wrangler secret put BETTER_AUTH_SECRET     # openssl rand -hex 32npx wrangler secret put CRON_SECRET            # any long random string; guards /internal/*

If wrangler asks to create the Worker first, answer yes. Optional: GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET add "Sign in with GitHub".

6. Deploy

bash
pnpm exec wrangler deploy                     # in apps/apicd ../web && pnpm build && pnpm exec wrangler deploy

Deploy the API first: the web Worker binds to it by name.

7. Check it

bash
curl https://status.example.com/api/health    # {"ok":true}

Open the domain and sign up. Once your own account exists you can set "DISABLE_SIGNUP": "true" in the API vars and deploy again to close registration (invited people can still join).

Upgrade later: pull, pnpm install, pnpm db:migrate, then deploy the API and the web Worker, in that order.

Self-host with Docker

One container runs the API, the web app and the check scheduler; Postgres comes with the compose file. Either run the published image or build it from source; the settings are the same.

Option A: run the published image

Tagged releases are published to ghcr.io/becoolme/openuptime for linux/amd64 and linux/arm64. You need no clone and no build:

bash
mkdir openuptime && cd openuptimecurl -fsSLO https://raw.githubusercontent.com/becoolme/openuptime/main/docker-compose.ymlcurl -fsSL https://raw.githubusercontent.com/becoolme/openuptime/main/.env.docker.example -o .env

Edit .env: set POSTGRES_PASSWORD and BETTER_AUTH_SECRET (openssl rand -hex 32), and uncomment OPENUPTIME_IMAGE. Pin a version (ghcr.io/becoolme/openuptime:0.1.0) or follow the newest release (:latest). Then:

bash
docker compose pull && docker compose up -d     # http://localhost:8080

Upgrade: change the tag if you pinned one, then run the same two commands again. Migrations run on start.

Option B: build from source

bash
git clone https://github.com/becoolme/openuptime.git && cd openuptimecp .env.docker.example .env      # set POSTGRES_PASSWORD and BETTER_AUTH_SECRET (openssl rand -hex 32)docker compose up -d --build     # http://localhost:8080

Upgrade: git pull, then docker compose up -d --build.

Either way

The schema is migrated on start and the data lives in the pgdata volume. Set PUBLIC_URL when the app is not served from http://localhost:8080. Email is optional; see Reference.

Once your own account exists, set DISABLE_SIGNUP=true in .env and run docker compose up -d to close registration (invited people can still join).

Develop

bash
pnpm installcp .env.example apps/api/.dev.vars   # edit DATABASE_URL and secretsDATABASE_URL=postgres://user:pass@localhost:5432/openuptime_dev pnpm db:migrate   # same URL as in .dev.varspnpm dev:api    # http://localhost:8787  (checks run inline every 15s)pnpm dev:web    # http://localhost:4321  (proxies /api to the API)pnpm typecheck

MCP server

Agents (Claude, Cursor, Codex and any MCP client) can manage monitors, incidents and status pages over Streamable HTTP at /api/mcp, authorizing with OAuth or an API key:

bash
claude mcp add --transport http openuptime https://openuptime.app/api/mcp   # or https://<your-host>/api/mcp

Client setup, scopes and the tool list are in the MCP docs. An agent skill that teaches the common workflows ships in skills/openuptime: npx skills add becoolme/openuptime. The hosted server is listed in the MCP Registry as app.openuptime/mcp; server.json is its entry.

Tests, how checks run, the MCP server, alert channels and the other details are in docs/reference.md.

Open source vs hosted

The monitoring itself is the same code in both. The hosted service at openuptime.app adds plans, billing and a few features that live only in that build; it plugs into this repo through one interface (Edition, see docs/editions.md), so nothing in the core is locked or throttled.

Self-hosted (this repo, MIT)Hosted (openuptime.app)
Monitors, incidents, status pages, alert channels, API, MCPAll of itAll of it
LimitsNone: no plans, quotas or meteringFree plan, paid plans from $5/month (pricing); monitors, checks, emails and history length depend on the plan
Running itYou: Postgres, the Worker or container, a mail provider, backups, upgradesWe do; nothing to install
SSL certificate monitoring (expiry alerts, ssl monitor type)Not includedLite and above
Custom domain for a status pageNot includedEvery paid plan (Lite and above), plus early-access workspaces
Where your data livesYour databaseOurs (Postgres on managed hosting)

Pick self-hosting if you want to own the data and the infrastructure, or have no limits to worry about. Pick hosted if you would rather not run anything. Both receive the same core updates.

Contributing & security

See CONTRIBUTING.md. Report vulnerabilities privately as described in SECURITY.md, not in public issues.

License

MIT

Source: README.md at commit 4a02d75

Tools

0
This server asks you to sign in, so SourceWeft could not read its tools without an account and has not indexed them. What a connected account sees can depend on that account and its permissions.

Version history

1
  1. v1.0.0LatestOct 15, 2026

Score

85% 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 listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts