# becoolme/openuptime

**Category:** 📊 Monitoring  
**Repository:** https://github.com/becoolme/openuptime  
**GitHub Stars:** 13  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/becoolme-openuptime

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

## Claude Desktop Quick Installation
No confirmed install details yet, so no config is published. Follow the setup steps in the repository above.

## Documentation

## What becoolme/openuptime MCP server does

The becoolme/openuptime MCP server exposes OpenUptime management functions to agents through the Model Context Protocol. Its documented scope covers uptime monitors, incidents, and status pages. That makes it suitable for workflows such as creating a monitor, recording an outage, updating an incident, or maintaining the information shown on a public status page.

OpenUptime itself supports several check types: HTTP, TCP, DNS, heartbeat, PostgreSQL, MySQL, and Redis. HTTP-style checks can use keyword matching and slow-response alerts. The monitoring application also supports maintenance windows, email and RSS subscriptions for status pages, and alert destinations including Slack, Lark or Feishu, Telegram, PagerDuty, webhooks, and email.

The MCP server is part of the broader OpenUptime application rather than a standalone monitoring engine. It uses the same workspace, project, role, API-key, and status-page model as the application. The repository is listed in the 📊 Monitoring category.

## How it works

Agents connect to the `/api/mcp` route using Streamable HTTP. The hosted endpoint is `https://openuptime.app/api/mcp`; a self-hosted deployment uses the equivalent path on its configured domain. Authentication can use OAuth or an API key, so the client must be configured with credentials accepted by the OpenUptime instance.

The README names Claude, Cursor, Codex, and other MCP clients as compatible. A typical Claude configuration uses an HTTP transport command pointing at the MCP URL. The available scopes and complete tool list are maintained in OpenUptime's MCP documentation, so review those details when restricting access or building an automated workflow.

## Setup and configuration

You can use the hosted OpenUptime service or deploy the open-source application yourself. The self-hosted repository supports Cloudflare Workers with Postgres, or a Docker deployment that combines the API, web application, scheduler, and Postgres service. Cloudflare deployment requires a Cloudflare account, a domain in a Cloudflare zone, an internet-reachable Postgres database, Node.js 22 or newer, and pnpm. The Cloudflare setup uses Hyperdrive for database access and normally uses a queue for scheduled checks.

The Docker option uses a `.env` file and exposes the application at port 8080 by default. Set `POSTGRES_PASSWORD` and `BETTER_AUTH_SECRET`; set `PUBLIC_URL` when the service is not running at the default local address. Database migrations run when the Docker application starts. For Cloudflare, configure `BETTER_AUTH_URL`, `WEB_ORIGIN`, and the authentication and cron secrets before deploying the API and web Workers.

After deployment, configure the MCP client with the instance URL and either OAuth or an API key. The repository also provides an installable agent skill through `npx skills add becoolme/openuptime`.

## Tools and capabilities

The becoolme/openuptime MCP server is intended to let agents manage:

- Uptime monitors
- Incidents
- Status pages

The underlying application can monitor HTTP, TCP, DNS, heartbeat, PostgreSQL, MySQL, and Redis targets. It can also represent maintenance windows, publish status pages, and route alerts through the channels supported by OpenUptime.

## Limitations and notes

The README does not enumerate the individual MCP tool names in the provided material; it directs users to the MCP documentation for the full tool list and scopes. Authorization is required through OAuth or an API key. Self-hosting also requires database, authentication, and deployment configuration, and Cloudflare's default queue-based setup requires a paid Workers plan unless inline mode is used.

The hosted build and the self-hosted repository share the monitoring, API, and MCP functionality, but the hosted service adds plan and billing features that are not part of the core self-hosted deployment.

_Full upstream README: https://allmcps.com/mcp/becoolme-openuptime/readme_