CoreDash-oppetids-API og MCP-verktøy: monitorer og sjekker

Oppetidsmonitorer over CoreDash-API-et

Les og endre oppetidsmonitorene i CoreDash-prosjektene dine over REST, med API-nøkkelen du allerede bruker til RUM-dataene dine. En AI-agent leser dem over MCP.

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

API-nøkler for oppetidsmonitorer

Oppetidsendepunktene godtar nøklene fra CoreDash-API-et og Agency-API-et.

Opprett en prosjektnøkkel på siden Connect Your AI i sidefeltet til prosjektet ditt: gi den et navn og klikk på Generate API key. De samme nøklene finner du i prosjektinnstillingene dine under API Keys (MCP). Kun prosjektets eiere kan opprette dem. En masternøkkel henter du fra siden Agency API i sidefeltet, på agency-kontoer. Når et prosjekt har utløpt, får prosjektnøkkelen 401 på alle kall.

En gjest i et prosjekt kan lese monitorene. Å legge til, endre, flytte og slette dem krever et prosjekt du eier.

OAuth-tokenet til en AI-tilkobling som Claude (mcp_at_) kan bare lese. POST, PATCH og DELETE med det får 403.

Oppetidsendepunkter

Origin-IP-en og header-verdiene er hemmelige. De returneres fra POST, PATCH og GET /api/uptime/monitors/:id. Listen og MCP-verktøyene utelater origin_ip og viser alle header-verdier som ••••.

Monitor-objektet

Feltene summary og rum

Både listen og den enkelte monitoren har en summary: rounds_7d og down_rounds_7d teller rundene de siste 7 dagene, uptime_7d er prosentandelen av disse rundene uten en nede-sjekk, og recent inneholder de siste 48 rundene, eldste først, hver med rundens dårligste utfall. En monitor uten sjekker de siste 7 dagene har summary: null.

Den enkelte monitoren har også rum: TTFB ved p75 som faktiske besøkende fikk de siste 7 dagene, hentet fra prosjektets RUM-data, for sammenligning med sjekkerens ttfb_ms. Den er null så lenge prosjektet mangler RUM-data.

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" }
}

I det faktiske svaret inneholder recent 48 runder; dette eksempelet viser de to siste.

Sjekkobjektet og utfallene

Hvert 30. minutt sjekker en runde alle monitorer, vekselvis fra to servere: scan1 ved :00, scan2 ved :30. En runde sjekker alltid URL-en slik besøkende når den, via DNS og CDN-et ditt (edge). Med en origin-IP sjekker den også serveren din direkte (origin). API-et har ingen kall for å sjekke en monitor mellom runder. Sjekkene lagres i 30 dager.

Hver sjekk sender user-agenten CoreDash/1.0 (uptime; +https://www.coredash.app/bot). Ligger monitorens URL på nettstedet til prosjektet ditt (hosten, med eller uten www, eller et subdomene), sender sjekken også headeren X-CoreDash-Bot med den hemmelige verdien til prosjektet ditt, fra CoreDash bot token-fanen i prosjektinnstillingene dine. En monitor på et annet nettsted får ingen token. Ved en redirect følger tokenet regelen for headers du har satt: det blir bare med så lenge redirecten holder seg på monitorens host. En egen header med navnet X-CoreDash-Bot droppes. CoreDash-bot-siden har mer om begge deler.

Hvordan en sjekk får utfallet sitt

Det verste utfallet blant sjekkene i en runde avgjør monitorens tilstand, fra verst til best: down, blocked, warn, up.

Monitortilstander

En monitor i et prosjekt der abonnementet har utløpt, beholder innstillingene sine og sin siste tilstand. Den sjekkes ikke før prosjektet er betalt igjen.

Legg til, endre og slett en monitor

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
  }'

Svaret er 201 med den nye monitoren, inkludert origin-IP og header-verdier:

{
  "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

Send bare feltene du endrer. headers erstatter hele listen, så send med alle headere du vil beholde. Dette pauser en 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 }'

Med en masternøkkel flytter project_id monitoren, etter de samme reglene som ved POST.

DELETE /api/uptime/monitors/:id

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

Dette kan ikke angres. Vil du stoppe sjekkene og beholde historikken, sender du { "paused": true } med PATCH.

Feil og begrensninger i oppetids-API-et

Feil returneres som { "error": "..." } med en av disse statuskodene:

Begrensninger: 25 monitorer per prosjekt, 5 ekstra headere per monitor, 2100 sjekker per GET av én monitor, og 30 dagers sjekkhistorikk.

MCP-verktøy for oppetid

CoreDash MCP-serveren på https://app.coredash.app/api/mcp har to oppetidsverktøy ved siden av RUM-verktøyene, pluss list_projects for prosjektene nøkkelen din når. Alle tre har bare lesetilgang. For å legge til, endre eller slette en monitor bruker du appen eller REST-endepunktene over med en CoreDash-API-nøkkel. Verktøyene trenger ingen project_id: en prosjektnøkkel leser sitt eget prosjekt, og en masternøkkel eller en OAuth-tilkobling som Claude leser alle prosjekter du eier eller ble invitert til.

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 }
    }
  }'

Svaret er JSON-RPC-wrapperen til CoreDash-API-et, med resultatet som en JSON-streng i result.content[0].text. En ukjent monitor gir { "error": "Monitor not found" } der, og result.isError er true.

Mer om oppetid og CoreDash-API-et

• Oppetidsovervåking: hva CoreDash sjekker og hva du ser i appen.
• CoreDash-API-et: prosjektnøkler, JSON-RPC-formatet og RUM-verktøyene.
• Agency-API-et: masternøkler og prosjekter over REST.
• CoreDash-bot: user-agenten, X-CoreDash-Bot-headeren og adressene.
• Slipp CoreDash gjennom brannmuren din: for en monitor som står som Blokkert.