Show HN: An uptime monitor with an MCP server, create monitors by asking Claude

luciandan1 pts0 comments

UptimeMonitoring.com — API-first uptime monitoring for deploy pipelines, developers, and AI agents

Get your API key

Menu

By Monitive · 16 years in monitoring · 50 monitors free · GitHub login · no email · no card

API-first uptime monitoring for deploy pipelines, developers, and AI agents.

Create monitors with a curl call, an MCP prompt, or a GitHub Action.

Create your first monitor

Read quickstart

claude — my-app

MCP &middot; Claude Code curl &middot; REST API GitHub Action<br>Connect (one command)<br>claude mcp add --transport http uptimemonitoring \<br>https://api.uptimemonitoring.com/mcp Copy

Then just ask Claude<br>❯ Create an HTTP monitor for https://example.com named "My Site"<br>❯ List my monitors<br>❯ What is the current status of monitor 123?<br>Copy

Have an API key? Add --header "Authorization: Bearer umk_live_..."<br>to authorize via key.

Create a monitor<br>curl -X POST https://api.uptimemonitoring.com/api/v1/monitors \<br>-H "Authorization: Bearer umk_live_..." \<br>-H "Content-Type: application/json" \<br>-d '{"name":"myapp-healthz","url":"https://myapp.com/healthz",<br>"type":"http","expected_status":"200"}' Copy

Check its state<br>curl https://api.uptimemonitoring.com/api/v1/monitors/123 \<br>-H "Authorization: Bearer umk_live_..." Copy

Post-deploy gate<br>- name: Verify deploy health<br>uses: uptimemonitoring/assert-healthy@v1<br>with:<br>api-key: ${{ secrets.UPTIMEMONITORING_API_KEY }}<br>monitor-id: ${{ vars.MONITOR_ID }}<br>timeout: 120 Copy<br>Fails the workflow if the monitor is not healthy after your deploy.

keys: app.uptimemonitoring.com/keys 60s checks &middot; 22 probe locations

16 years of monitoring infrastructure &middot;<br>22 global probe locations &middot;<br>Cross-region confirmation on every failure &middot;<br>Evidence buffer included with every incident &middot;<br>GitHub OAuth + API key in minutes

Use the surface you already work in.

Same backend. Same monitor state. Different ways to drive it.

REST API MCP<br>Create and manage monitors from scripts, apps, or CI.<br>bash<br>curl -X POST https://api.uptimemonitoring.com/api/v1/monitors \<br>-H "Authorization: Bearer $UPTIMEMONITORING_API_KEY" \<br>-H "Content-Type: application/json" \<br>-d '{<br>"name": "api-prod",<br>"url": "https://api.example.com/healthz",<br>"type": "http"<br>}'

Let Claude, ChatGPT, or Cursor create, inspect, and assert monitor health for you.<br>text<br>User:<br>Create a 60-second monitor for https://api.example.com/healthz<br>and tell me if it is healthy right now.

Tool:<br>create_monitor

Result:<br>Monitor created: api-prod<br>Current status: up<br>Last evidence: EU · 200 · ttfb 184ms

Built for your workflow

Pick the surface that fits how you ship.

Fail deploys when your site is down<br>Use a GitHub Action to assert your deploy is reachable from 22 probe locations before traffic switches over.<br>→ Let your Claude agent monitor its own deployments<br>Add the UptimeMonitoring MCP server to Claude Code so your agent can create monitors, check status, and react to failures.<br>→ Uptime monitoring from inside Cursor<br>Configure UptimeMonitoring as an MCP server in Cursor and manage monitors from the agent panel.<br>→ Monitor any API with 50 free checks<br>Create monitors via the REST API with a single POST request — no dashboard required.

What happens when something breaks

We do not flip red on the first blip.

Create<br>You create a monitor through the API, MCP, or GitHub Action.

Test immediately<br>We run an immediate test check so typos and unreachable targets fail fast.

Check on schedule<br>Checks are spread across the minute to keep load stable.

Re-check failures<br>Infrastructure-class failures are confirmed from two additional regions before we flip state.

Deliver evidence<br>We store the incident with evidence and send it where you want it: webhook, browser push, RSS, or MCP pull.

check log<br>US-W ● 200 05:37:41 ← healthy<br>US-W ✗ dns 05:38:42 ← first failure<br>EU ✗ dns 05:38:44 ← recheck #1<br>US-E ✗ dns 05:38:46 ← recheck #2<br>→ incident created

Evidence, not just red dots

See what happened before the incident: DNS, TLS, timeout, 5xx, region, and timing breakdowns.

Last 20 checks included<br>Timing breakdowns per check<br>Region-aware evidence<br>Designed for debugging, not dashboards

incident evidence<br>"id": 194,<br>"type": "down",<br>"monitor_id": 1287,<br>"started_at": "2026-04-18T05:38:52Z",<br>"resolved_at": "2026-04-18T05:45:44Z",<br>"evidence": [<br>"region": "US-W",<br>"timestamp": "2026-04-18T05:37:41Z",<br>"status_code": 200,<br>"dns_ms": 6.8,<br>"tls_ms": 298,<br>"connect_ms": 149,<br>"ttfb_ms": 203<br>},<br>"region": "US-W",<br>"timestamp": "2026-04-18T05:38:42Z",<br>"error_class": "dns"

Webhooks for systems. Push for humans. MCP for agents.

No inbox spam. No deliverability headaches. You choose the channel.

Webhooks<br>For Slack, Twilio, Discord, ntfy, GitHub Actions, or your own router.<br>PUT /api/v1/monitors/1287/webhook<br>{ "url": "https://hooks.co/inc" }

Browser push<br>One-click opt-in from the dashboard. Fastest human fallback.<br>Enable notifications<br>Chrome on macOS · Active

RSS / incident feed<br>Subscribe from Slack, readers, or automation...

monitor create monitors middot uptimemonitoring https

Related Articles