CoreDash Uptime API i narzędzia MCP: monitory i sprawdzenia

Monitory uptime przez API CoreDash

Odczytuj i zmieniaj monitory uptime w projektach CoreDash przez REST za pomocą tego samego klucza API, którego używasz do danych RUM. Agent AI odczytuje je przez MCP.

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

Klucze API do monitorów uptime

Endpointy uptime obsługują klucze z CoreDash API oraz Agency API.

Klucz projektu wygenerujesz na stronie Connect Your AI w pasku bocznym projektu: nadaj mu nazwę i kliknij Generate API key. Te same klucze znajdziesz w ustawieniach projektu w sekcji API Keys (MCP). Mogą je tworzyć tylko właściciele projektu. Klucz master wygenerujesz na stronie Agency API w pasku bocznym – na kontach agencyjnych. Gdy projekt wygaśnie, jego klucz projektu zwraca 401 przy każdym wywołaniu.

Gość w projekcie może jedynie odczytywać monitory. Dodawanie, modyfikowanie, przenoszenie i usuwanie wymaga projektu, którego jesteś właścicielem.

Token OAuth połączenia AI, takiego jak Claude (mcp_at_), pozwala wyłącznie na odczyt. Żądania POST, PATCH i DELETE z jego użyciem zwracają 403.

Endpointy uptime

Adres IP serwera origin oraz wartości nagłówków to dane poufne. Zwracają je metody POST, PATCH i GET /api/uptime/monitors/:id. Zwykła lista oraz narzędzia MCP pomijają origin_ip, a każdą wartość nagłówka maskują jako ••••.

Obiekt monitora

Pola summary i rum

Zarówno lista, jak i pojedynczy monitor zawierają pole summary: rounds_7d i down_rounds_7d zliczają rundy z ostatnich 7 dni, uptime_7d to odsetek tych rund bez sprawdzenia zakończonego statusem down, a recent przechowuje ostatnie 48 rund (od najstarszej), każda z najgorszym wynikiem w danej rundzie. Monitor bez sprawdzeń w ciągu ostatnich 7 dni ma summary: null.

Pojedynczy monitor zawiera także pole rum: TTFB na poziomie p75, jaki mieli rzeczywiści użytkownicy w ostatnich 7 dniach (z danych RUM projektu), do porównania z ttfb_ms bota sprawdzającego. Dopóki projekt nie ma danych RUM, pole ma wartość 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" }
}

W rzeczywistej odpowiedzi tablica recent zawiera 48 rund – ten przykład pokazuje dwie ostatnie.

Obiekt sprawdzenia i jego wyniki

Co 30 minut uruchamia się runda sprawdzająca każdy monitor, naprzemiennie z dwóch serwerów: scan1 o :00 i scan2 o :30. Runda zawsze sprawdza URL tak, jak docierają do niego użytkownicy – przez DNS i CDN (edge). Po podaniu IP serwera origin sprawdza też bezpośrednio sam serwer (origin). API nie pozwala wywołać sprawdzenia między rundami. Historia sprawdzeń jest przechowywana przez 30 dni.

Każde sprawdzenie wysyła user agent CoreDash/1.0 (uptime; +https://www.coredash.app/bot). Gdy URL monitora znajduje się w domenie projektu (w jego hoście, z www lub bez, albo w subdomenie), sprawdzenie wysyła także nagłówek X-CoreDash-Bot z tajną wartością projektu, pobraną z zakładki CoreDash bot token w ustawieniach projektu. Monitor w jakiejkolwiek innej witrynie nie otrzymuje tokena. Przy przekierowaniu token zachowuje się zgodnie z regułą dla zdefiniowanych nagłówków (headers): jest przekazywany tylko dopóki przekierowanie pozostaje na hoście monitora. Własny nagłówek o nazwie X-CoreDash-Bot jest odrzucany. Szczegóły obu mechanizmów opisuje strona bota CoreDash.

Jak ustalany jest wynik sprawdzenia

O stanie monitora decyduje najgorszy wynik sprawdzeń w danej rundzie, w kolejności od najgorszego: down, blocked, warn, up.

Stany monitora

Monitor w projekcie, którego subskrypcja wygasła, zachowuje swoje ustawienia i ostatni stan. Nie jest sprawdzany do momentu opłacenia projektu.

Dodawanie, edycja i usuwanie monitora

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

Odpowiedź to 201 z nowym monitorem, w tym z adresem IP origin i wartościami nagłówków:

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

Przesyłaj tylko zmieniane pola. Pole headers zastępuje całą listę, więc wyślij wszystkie nagłówki, które chcesz zachować. Poniższe wywołanie wstrzymuje 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 }'

Przy użyciu klucza master pole project_id przenosi monitor – na takich samych zasadach jak przy POST.

DELETE /api/uptime/monitors/:id

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

Operacji nie można cofnąć. Aby zatrzymać sprawdzanie i zachować historię, wyślij { "paused": true } za pomocą PATCH.

Błędy i limity w Uptime API

Błędy są zwracane jako { "error": "..." } z jednym z poniższych statusów:

Limity: 25 monitorów na projekt, 5 dodatkowych nagłówków na monitor, 2100 sprawdzeń na jedno zapytanie GET pojedynczego monitora oraz 30 dni historii sprawdzeń.

Narzędzia MCP dla uptime

Serwer MCP CoreDash pod adresem https://app.coredash.app/api/mcp oferuje dwa narzędzia uptime (obok narzędzi RUM) oraz list_projects dla projektów dostępnych dla danego klucza. Wszystkie trzy służą wyłącznie do odczytu. Aby dodać, zmienić lub usunąć monitor, skorzystaj z aplikacji lub z powyższych endpointów REST z kluczem CoreDash API. Narzędzia te nie wymagają parametru project_id: klucz projektu odczytuje własny projekt, a klucz master lub połączenie OAuth (np. Claude) odczytuje wszystkie projekty, których jesteś właścicielem lub do których masz zaproszenie.

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

Odpowiedź to wrapper JSON-RPC z CoreDash API, z wynikiem w postaci ciągu JSON w result.content[0].text. Nieznany monitor zwraca tam { "error": "Monitor not found" }, a pole result.isError przyjmuje wartość true.

Więcej o uptime i CoreDash API

• Monitoring uptime: co sprawdza CoreDash i co widać w aplikacji.
• CoreDash API: klucze projektu, format JSON-RPC i narzędzia RUM.
• Agency API: klucze master i projekty przez REST.
• Bot CoreDash: user agent, nagłówek X-CoreDash-Bot i adresy IP.
• Przepuść CoreDash przez firewall: dla monitora ze statusem Blocked.