CoreDash-Uptime-API und MCP-Tools: Monitore und Checks

Uptime-Monitore über die CoreDash-API

Lies und ändere die Uptime-Monitore deiner CoreDash-Projekte über REST – mit dem API-Key, den du schon für deine RUM-Daten nutzt. Ein KI-Agent liest sie über MCP.

curl https://app.coredash.app/api/uptime/monitors \
  -H "Authorization: Bearer cdk_your_key"

API-Keys für Uptime-Monitore

Die Uptime-Endpunkte akzeptieren die Keys der CoreDash-API und der Agency-API.

Erstelle einen Projekt-Key auf der Seite „Connect Your AI“ in der Sidebar deines Projekts: Gib ihm einen Namen und klicke auf „Generate API key“. Dieselben Keys findest du in deinen Projekteinstellungen unter „API Keys (MCP)“. Nur Owner eines Projekts können sie anlegen. Einen Master-Key gibt es auf der Seite „Agency API“ in der Sidebar bei Agency-Accounts. Ist ein Projekt abgelaufen, liefert sein Projekt-Key bei jedem Aufruf einen 401.

Als Gast in einem Projekt kannst du dessen Monitore lesen. Hinzufügen, Ändern, Verschieben und Löschen geht nur bei Projekten, die dir gehören.

Das OAuth-Token einer KI-Verbindung wie Claude (mcp_at_) liest nur. POST, PATCH und DELETE liefern damit einen 403.

Uptime-Endpunkte

Die Origin-IP und die Header-Werte sind geheim. POST, PATCH und GET /api/uptime/monitors/:id geben sie zurück. Die Liste und die MCP-Tools lassen origin_ip weg und zeigen jeden Header-Wert als ••••.

Das Monitor-Objekt

Die Felder summary und rum

Sowohl die Liste als auch der einzelne Monitor enthalten ein summary: rounds_7d und down_rounds_7d zählen die Runden der letzten 7 Tage, uptime_7d ist der Prozentsatz dieser Runden ohne Down-Check und recent enthält die letzten 48 Runden (älteste zuerst), jeweils mit dem schlechtesten Ergebnis der Runde. Ein Monitor ohne Checks in den letzten 7 Tagen hat summary: null.

Der einzelne Monitor enthält außerdem rum: die TTFB bei p75, die deine echten Besucher in den letzten 7 Tagen hatten, aus den RUM-Daten des Projekts – zum Vergleich mit der ttfb_ms des Checkers. Hat das Projekt keine RUM-Daten, ist das Feld null.

GET /api/uptime/monitors/:id

curl "https://app.coredash.app/api/uptime/monitors/6ad68c7a844fad80b752fd16?limit=2" \
  -H "Authorization: Bearer cdk_your_key"

{
  "monitor": {
    "id": "6ad68c7a844fad80b752fd16",
    "name": "Checkout",
    "url": "https://www.example.com/checkout/",
    "project_id": "655f1f77bcf86cd799439011",
    "paused": false,
    "expect_status": 200,
    "origin_check": true,
    "origin_ip": "203.0.113.10",
    "headers": [{ "name": "X-Staging-Auth", "value": "k7Qp2vX9mR4tL8wZ" }],
    "state": "up",
    "last_check_at": "2026-10-20T08:00:09.000Z",
    "last_up_at": "2026-10-20T08:00:09.000Z",
    "down_since": null,
    "last_down": { "from": "2026-10-18T19:00:11.000Z", "to": "2026-10-18T20:00:10.000Z" },
    "check_requested_at": null,
    "last": {
      "edge": { "at": "2026-10-20T08:00:09.000Z", "server": "scan1", "mode": "edge", "outcome": "up", "status": 200, "ttfb_ms": 212, "total_ms": 388, "connect_ms": 14, "redirects": 0, "final_url": "https://www.example.com/checkout/", "error": null, "error_text": null, "cloudflare": true, "cache_status": "DYNAMIC" },
      "origin": { "at": "2026-10-20T08:00:09.000Z", "server": "scan1", "mode": "origin", "outcome": "up", "status": 200, "ttfb_ms": 640, "total_ms": 702, "connect_ms": 9, "redirects": 0, "final_url": "https://www.example.com/checkout/", "error": null, "error_text": null, "cloudflare": false, "cache_status": null },
      "origin_is_cdn": false
    },
    "cert_expires": "2027-01-02T23:59:59.000Z",
    "created_at": "2026-10-06T09:12:41.000Z"
  },
  "summary": {
    "rounds_7d": 336,
    "down_rounds_7d": 2,
    "uptime_7d": 99.4,
    "recent": [
      { "at": "2026-10-20T07:30:10.000Z", "outcome": "up" },
      { "at": "2026-10-20T08:00:09.000Z", "outcome": "up" }
    ]
  },
  "checks": [
    { "at": "2026-10-20T08:00:09.000Z", "server": "scan1", "mode": "edge", "outcome": "up", "status": 200, "ttfb_ms": 212, "total_ms": 388, "connect_ms": 14, "redirects": 0, "final_url": "https://www.example.com/checkout/", "error": null, "error_text": null, "cloudflare": true, "cache_status": "DYNAMIC" },
    { "at": "2026-10-20T08:00:09.000Z", "server": "scan1", "mode": "origin", "outcome": "up", "status": 200, "ttfb_ms": 640, "total_ms": 702, "connect_ms": 9, "redirects": 0, "final_url": "https://www.example.com/checkout/", "error": null, "error_text": null, "cloudflare": false, "cache_status": null }
  ],
  "rum": { "ttfb_p75": 1920, "rating": "poor", "period": "last 7 days" }
}

In der echten Antwort enthält recent 48 Runden; dieses Beispiel zeigt die letzten zwei.

Das Check-Objekt und seine Ergebnisse

Alle 30 Minuten prüft eine Runde jeden Monitor, abwechselnd von zwei Servern: scan1 um :00, scan2 um :30. Eine Runde prüft die URL immer so, wie Besucher sie erreichen: über DNS und dein CDN (edge). Mit einer Origin-IP prüft sie deinen Server zusätzlich direkt (origin). Die API bietet keinen Aufruf, um einen Monitor zwischen den Runden zu prüfen. Checks werden 30 Tage gespeichert.

Jeder Check sendet den User-Agent CoreDash/1.0 (uptime; +https://www.coredash.app/bot). Liegt die URL des Monitors auf der Website deines Projekts (auf dem Host mit oder ohne www oder einer Subdomain), sendet der Check auch den Header X-CoreDash-Bot mit dem geheimen Wert deines Projekts aus dem Tab „CoreDash bot token“ in deinen Projekteinstellungen. Ein Monitor auf jeder anderen Website bekommt kein Token. Bei einem Redirect folgt das Token der Regel für deine gesetzten headers: Es wird nur mitgeschickt, solange der Redirect auf dem Host des Monitors bleibt. Ein eigener Header namens X-CoreDash-Bot wird verworfen. Mehr zu beidem erfährst du auf der Seite CoreDash-Bot.

Wie ein Check sein Ergebnis ermittelt

Das schlechteste Ergebnis der Checks einer Runde bestimmt den Status des Monitors, von schlecht nach gut: down, blocked, warn, up.

Monitor-Status

Ein Monitor in einem Projekt mit abgelaufenem Abo behält seine Einstellungen und seinen letzten Status. Er wird erst wieder geprüft, sobald das Projekt wieder bezahlt ist.

Monitor anlegen, ändern und löschen

POST /api/uptime/monitors

curl -X POST https://app.coredash.app/api/uptime/monitors \
  -H "Authorization: Bearer cdk_master_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://www.example.com/checkout/",
    "name": "Checkout",
    "project_id": "655f1f77bcf86cd799439011",
    "origin_ip": "203.0.113.10",
    "headers": [{ "name": "X-Staging-Auth", "value": "k7Qp2vX9mR4tL8wZ" }],
    "expect_status": 200
  }'

Die Antwort ist 201 mit dem neuen Monitor inklusive Origin-IP und Header-Werten:

{
  "monitor": {
    "id": "6ad68c7a844fad80b752fd16",
    "name": "Checkout",
    "url": "https://www.example.com/checkout/",
    "project_id": "655f1f77bcf86cd799439011",
    "paused": false,
    "expect_status": 200,
    "origin_check": true,
    "origin_ip": "203.0.113.10",
    "headers": [{ "name": "X-Staging-Auth", "value": "k7Qp2vX9mR4tL8wZ" }],
    "state": "pending",
    "last_check_at": null,
    "last_up_at": null,
    "down_since": null,
    "last_down": null,
    "check_requested_at": "2026-10-20T09:12:41.000Z",
    "last": {},
    "cert_expires": null,
    "created_at": "2026-10-20T09:12:41.000Z"
  }
}

PATCH /api/uptime/monitors/:id

Sende nur die Felder, die du änderst. headers ersetzt die gesamte Liste – schicke also jeden Header mit, den du behalten willst. So pausierst du einen Monitor:

curl -X PATCH https://app.coredash.app/api/uptime/monitors/6ad68c7a844fad80b752fd16 \
  -H "Authorization: Bearer cdk_your_key" \
  -H "Content-Type: application/json" \
  -d '{ "paused": true }'

Mit einem Master-Key verschiebt project_id den Monitor nach denselben Regeln wie bei POST.

DELETE /api/uptime/monitors/:id

curl -X DELETE https://app.coredash.app/api/uptime/monitors/6ad68c7a844fad80b752fd16 \
  -H "Authorization: Bearer cdk_your_key"

Es gibt kein Undo. Um die Checks zu stoppen und den Verlauf zu behalten, sende { "paused": true } per PATCH.

Uptime-API: Fehler und Limits

Fehler kommen als { "error": "..." } mit einem dieser Status zurück:

Limits: 25 Monitore pro Projekt, 5 zusätzliche Header pro Monitor, 2100 Checks pro GET eines Monitors und 30 Tage Check-Verlauf.

Uptime-MCP-Tools

Der CoreDash-MCP-Server unter https://app.coredash.app/api/mcp bietet neben den RUM-Tools zwei Uptime-Tools sowie list_projects für alle Projekte, die dein Key erreicht. Alle drei lesen nur. Um Monitore anzulegen, zu ändern oder zu löschen, nutze die App oder die obigen REST-Endpunkte mit einem CoreDash-API-Key. Die Tools brauchen keine project_id: Ein Projekt-Key liest das eigene Projekt; ein Master-Key oder eine OAuth-Verbindung wie Claude liest jedes Projekt, das du besitzt oder zu dem du eingeladen wurdest.

curl -X POST https://app.coredash.app/api/mcp \
  -H "Authorization: Bearer cdk_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "get_uptime_monitor",
      "arguments": { "monitor_id": "6ad68c7a844fad80b752fd16", "limit": 48 }
    }
  }'

Die Antwort ist der JSON-RPC-Wrapper der CoreDash-API, mit dem Ergebnis als JSON-String in result.content[0].text. Ein unbekannter Monitor liefert dort { "error": "Monitor not found" }, und result.isError ist true.

Mehr zu Uptime und der CoreDash-API

• Uptime-Monitoring: Was CoreDash prüft und was du in der App siehst.
• CoreDash-API: Projekt-Keys, das JSON-RPC-Format und die RUM-Tools.
• Agency-API: Master-Keys und Projekte über REST.
• CoreDash-Bot: Der User-Agent, der Header X-CoreDash-Bot und die Adressen.
• Lass CoreDash durch deine Firewall: Für einen Monitor, der „Blocked“ anzeigt.