API de uptime y herramientas MCP de CoreDash: monitores y comprobaciones

Monitores de uptime con la API de CoreDash

Consulta y modifica los monitores de uptime de tus proyectos en CoreDash mediante REST, con la clave de API que ya usas para los datos de RUM. Un agente de IA los lee mediante MCP.

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

Claves de API para monitores de uptime

Los endpoints de uptime admiten las claves de la API de CoreDash y de la Agency API.

Crea una clave de proyecto en la página Connect Your AI, en la barra lateral del proyecto: asígnale un nombre y haz clic en Generate API key. Estas mismas claves están en la configuración del proyecto, en API Keys (MCP). Solo los propietarios del proyecto pueden crearlas. La clave maestra se obtiene en la página Agency API de la barra lateral, en cuentas de agencia. Si el proyecto caduca, su clave de proyecto recibe un 401 en cada llamada.

Un invitado en un proyecto solo lee sus monitores. Para añadirlos, modificarlos, moverlos y eliminarlos necesitas un proyecto propio.

El token OAuth de una conexión de IA como Claude (mcp_at_) es de solo lectura. Cualquier POST, PATCH o DELETE con este token recibe un 403.

Endpoints de uptime

La IP de origen y los valores de las cabeceras son secretos. Se devuelven en POST, PATCH y GET /api/uptime/monitors/:id. El listado y las herramientas MCP omiten origin_ip y muestran el valor de cada cabecera como ••••.

El objeto monitor

Los campos summary y rum

Tanto el listado como el monitor individual incluyen un summary: rounds_7d y down_rounds_7d cuentan las rondas de los últimos 7 días, uptime_7d es el porcentaje de esas rondas sin ninguna comprobación en down, y recent contiene las últimas 48 rondas, de más antigua a más reciente, cada una con el peor resultado de esa ronda. Si un monitor no tiene comprobaciones en los últimos 7 días, devuelve summary: null.

El monitor individual también incluye rum: el TTFB en p75 que obtuvieron los visitantes reales en los últimos 7 días, a partir de los datos de RUM del proyecto, para compararlo con el ttfb_ms del comprobador. Es null mientras el proyecto no tenga datos de RUM.

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

En la respuesta real, recent contiene 48 rondas; este ejemplo muestra las dos últimas.

El objeto check y sus resultados

Cada 30 minutos una ronda comprueba todos los monitores, alternando entre dos servidores: scan1 a las :00 y scan2 a las :30. La ronda siempre comprueba la URL tal como acceden los visitantes: mediante DNS y el CDN (edge). Si se define una IP de origen, también comprueba el servidor directamente (origin). La API no ofrece ninguna llamada para comprobar un monitor entre rondas. Las comprobaciones se conservan durante 30 días.

Cada comprobación envía el user agent CoreDash/1.0 (uptime; +https://www.coredash.app/bot). Si la URL del monitor pertenece al propio sitio del proyecto (su host, con o sin www, o un subdominio), la comprobación incluye además la cabecera X-CoreDash-Bot con el valor secreto del proyecto, obtenido en la pestaña CoreDash bot token dentro de la configuración del proyecto. Un monitor en cualquier otro sitio no recibe ningún token. Si hay una redirección, el token sigue la regla de las headers configuradas: solo se conserva mientras la redirección permanezca en el host del monitor. Cualquier cabecera propia llamada X-CoreDash-Bot se descarta. La página del bot de CoreDash incluye más información sobre ambos aspectos.

Cómo se determina el resultado de una comprobación

El peor resultado entre las comprobaciones de una ronda determina el estado del monitor, de peor a mejor: down, blocked, warn, up.

Estados del monitor

Un monitor de un proyecto cuya suscripción haya finalizado conserva su configuración y su último estado. No se vuelve a comprobar hasta que el proyecto se pague de nuevo.

Cómo añadir, modificar y eliminar un 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
  }'

La respuesta es 201 con el nuevo monitor, incluyendo la IP de origen y los valores de las cabeceras:

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

Envía solo los campos que cambies. headers reemplaza la lista completa, así que envía todas las cabeceras que quieras conservar. Así se pausa un 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 }'

Con una clave maestra, project_id mueve el monitor siguiendo las mismas reglas que en POST.

DELETE /api/uptime/monitors/:id

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

No se puede deshacer. Para detener las comprobaciones y conservar el historial, envía { "paused": true } con PATCH.

Errores y límites de la API de uptime

Los errores devuelven { "error": "..." } con uno de estos estados:

Límites: 25 monitores por proyecto, 5 cabeceras adicionales por monitor, 2100 comprobaciones por GET de un monitor y 30 días de historial de comprobaciones.

Herramientas MCP de uptime

El servidor MCP de CoreDash en https://app.coredash.app/api/mcp incluye dos herramientas de uptime junto a las de RUM, además de list_projects para los proyectos accesibles con tu clave. Las tres son de solo lectura. Para añadir, modificar o eliminar un monitor, usa la app o los endpoints REST anteriores con una clave de API de CoreDash. Las herramientas no necesitan project_id: una clave de proyecto lee su propio proyecto; una clave maestra o una conexión OAuth como Claude lee todos los proyectos propios o a los que te hayan invitado.

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

La respuesta sigue el formato JSON-RPC de la API de CoreDash, con el resultado como una cadena JSON en result.content[0].text. Si el monitor no existe, devuelve { "error": "Monitor not found" } en ese campo y result.isError es true.

Más sobre uptime y la API de CoreDash

• Monitorización de uptime: qué comprueba CoreDash y qué ves en la app.
• API de CoreDash: claves de proyecto, formato JSON-RPC y herramientas de RUM.
• Agency API: claves maestras y proyectos mediante REST.
• Bot de CoreDash: el user agent, la cabecera X-CoreDash-Bot y las direcciones.
• Permite el paso de CoreDash en tu firewall: para un monitor que indique Bloqueado.