Examples

The target hostname must resolve at creation time. The snippets below use https://example.com/ because it actually resolves and returns 200 — fine for a smoke test. In real use, point at your own service (e.g. https://api.your-domain.com/healthz).

curl

Create a monitor from any terminal:

curl -X POST https://api.uptimemonitoring.com/api/v1/monitors \
  -H "Authorization: Bearer $UPTIMEMONITORING_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "api-prod",
    "url": "https://example.com",
    "type": "http"
  }'

Node.js

const res = await fetch("https://api.uptimemonitoring.com/api/v1/monitors", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.UPTIMEMONITORING_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    name: "api-prod",
    url: "https://example.com",
    type: "http",
  }),
});

const data = await res.json();
console.log(`Monitor ${data.monitor.id} created, status: ${data.state.status}`);

Python

import os
import requests

resp = requests.post(
    "https://api.uptimemonitoring.com/api/v1/monitors",
    headers={"Authorization": f"Bearer {os.environ['UPTIMEMONITORING_API_KEY']}"},
    json={
        "name": "api-prod",
        "url": "https://example.com",
        "type": "http",
    },
)

data = resp.json()
print(f"Monitor {data['monitor']['id']} created, status: {data['state']['status']}")

GitHub Actions

Post-deploy health gate

name: Deploy and verify
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh

      - name: Verify deploy health
        uses: uptimemonitoring/assert-healthy@v1
        with:
          api-key: ${{ secrets.UPTIMEMONITORING_API_KEY }}
          monitor-ids: ${{ vars.MONITOR_ID }}

Claude / Claude Code

Add UptimeMonitoring as an MCP server
Create a monitor for https://example.com/
Assert that it is healthy after deploy

MCP configuration:

{
  "mcpServers": {
    "uptimemonitoring": {
      "url": "https://api.uptimemonitoring.com/mcp",
      "headers": {
        "Authorization": "Bearer umk_live_..."
      }
    }
  }
}

Cursor

Add to .cursor/mcp.json:

{
  "mcpServers": {
    "uptimemonitoring": {
      "url": "https://api.uptimemonitoring.com/mcp",
      "headers": {
        "Authorization": "Bearer umk_live_..."
      }
    }
  }
}

Then use natural language:

Create a monitor for https://example.com/
and tell me if it is healthy

Webhook recipients

Webhooks are account-level recipients — create one, then attach it to any number of monitors (see Choose who gets alerts):

# Create a webhook recipient pointed at your own endpoint
curl -X POST https://api.uptimemonitoring.com/api/v1/recipients \
  -H "Authorization: Bearer $UPTIMEMONITORING_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"ops-webhook","type":"webhook","config":{"url":"https://hooks.example.com/incident"}}'
# -> {"id": 42, ..., "secret": "whs_live_…"}

# Read monitor 1287's current recipients before attaching the new one —
# PUT replaces the complete set, so skipping this step would detach
# every recipient already on the monitor
CURRENT=$(curl -s https://api.uptimemonitoring.com/api/v1/monitors/1287/recipients \
  -H "Authorization: Bearer $UPTIMEMONITORING_API_KEY")
# -> {"recipients": [{"id": 10, "down_delay_s": 60}]}

# Build the full set from what the GET actually returned — the existing
# recipient (with its existing down_delay_s) plus the new one. Requires jq.
BODY=$(echo "$CURRENT" | jq '{recipients: (.recipients + [{id: 42, down_delay_s: 0}])}')
curl -X PUT https://api.uptimemonitoring.com/api/v1/monitors/1287/recipients \
  -H "Authorization: Bearer $UPTIMEMONITORING_API_KEY" \
  -H "Content-Type: application/json" \
  -d "$BODY"

The HMAC secret is returned only in the recipient-creation response; store it for signature verification. This read-then-write sequence has no concurrency protection — the PUT carries no version, ETag, or If-Match precondition, so a concurrent editor can silently overwrite your change. Edit a monitor’s recipients from one place at a time, and re-read the result after saving to confirm it matches what you intended; see Choose who gets alerts for the full warning.

A type: "webhook" recipient’s payload isn’t the shape Slack, Discord, Pushover, or ntfy expect. If you want one of those destinations: um-api accepts native type: "slack" and type: "pagerduty" recipients directly (no dashboard UI yet — create them through the API); for anything else with no native recipient type, use the open-source alert-bridge relay instead of pointing a webhook recipient’s URL directly at it.