Monitorear disponibilidad
Decida cada cuánto se revisa un sitio: cada pocos minutos para una tienda crítica o cada hora para una página tranquila. Cada revisión mira si respondió y en cuánto tiempo, y usted solo recibe aviso cuando se cae o vuelve. Paga por uso, sin suscripción.
La mayoría de las herramientas de disponibilidad revisan según su propio reloj, coincida o no con la forma real en que necesita vigilar su infraestructura.
Vigilancia a su ritmo, no al de un proveedor
La mayoría de los monitores de disponibilidad funcionan como un servicio fijo que revisa según su propio reloj, algo que a unos equipos les sirve y a otros no. Si usted ya tiene un programador de tareas o su propia automatización, lo lógico es decidir el ritmo por su cuenta. Aquí registra un monitor con la dirección que quiere vigilar y cada cuánto revisarla: cada pocos minutos para una tienda crítica, una vez por hora para una página más tranquila o con más frecuencia durante un despliegue. A partir de ahí las comprobaciones siguen exactamente esa cadencia, sin que nadie tenga que mirar un panel.
Qué mira cada comprobación y cuándo se entera usted
En cada pasada el monitor se pregunta tres cosas: si el sitio respondió, qué respuesta dio y cuánto tardó. Luego lo compara con el resultado anterior. Usted recibe aviso solo cuando el estado cambia, es decir, cuando la web se cae y otra vez cuando vuelve, no tras cada revisión rutinaria sin novedades. Así las alertas conservan su valor: si llega un mensaje, es que pasó algo de verdad. El registro se confirma al momento y la vigilancia continúa en segundo plano con el calendario que usted fijó.
Disponibilidad a la cadencia que usted fije
Los monitores de disponibilidad tradicionales corren como un servicio permanente en el intervalo predeterminado de un proveedor, y ese modelo funciona bien para algunos equipos y mal para otros. Cualquiera que ya opere su propio programador, orquestador o infraestructura de cron suele querer decidir la cadencia él mismo: registrar un monitor, fijar cada cuánto comprueba —cada pocos minutos para una tienda crítica, cada hora para una página más tranquila— y dejar que corra al ritmo exacto que su infraestructura necesita en lugar de uno fijo que no puede cambiar.
Preguntas frecuentes
¿El monitoreo de disponibilidad tiene una versión gratuita?
No hay capa gratuita: las capas gratis se abusan y ralentizan a todos. Sin suscripción, sin tokens ni créditos inventados, y una tarea fallida no se cobra.
¿Qué pasa si la verificación misma da timeout o falla?
La tarea se reintenta automáticamente hasta tres veces; si sigue fallando, recibe un error claro en lugar de un resultado ambiguo, y el intento fallido no se cobra.
¿Cada cuánto se puede revisar mi sitio?
Tan a menudo como usted decida. Fija el ritmo al registrar el monitor con el formato habitual de calendario de cinco partes: cada pocos minutos para una tienda crítica, cada hora para una página tranquila o con más frecuencia durante un despliegue.
¿Recibiré un aviso después de cada revisión?
No. Solo recibe aviso cuando el estado cambia: una vez cuando el sitio se cae y otra cuando vuelve. Las revisiones rutinarias sin novedades no generan mensajes, así que cada alerta significa que pasó algo de verdad.
¿Puedo vigilar un dominio en lugar de la dirección de una página?
Sí. Puede indicar la dirección de la página que quiere vigilar o solo el dominio que le interesa. En ambos casos se comprueba, con el ritmo que usted fijó, si responde y cuánto tarda en hacerlo.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. Esta capacidad está disponible actualmente mediante la API, no como herramienta interactiva en la Web.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/web/uptime \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://example.com"}'const res = await fetch("https://api.kit.forhosting.com/web/uptime", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"url": "https://example.com"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/uptime",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"url": "https://example.com"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/uptime", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"url":"https://example.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://example.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/uptime", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"url": "https://example.com"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.uptime",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Límites
timeout_sec | 30 |
max_crawl_pages | 25 |
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
Esta api para monitorear si una web está caída pone el reloj en sus manos: usted registra un monitor desde su propia automatización, fija cada cuánto se ejecuta, y la comprobación corre a esa cadencia y llama a su webhook cuando el estado cambia, de modo que la vigilancia ocurre por usted sin depender de que alguien mire un tablero.
Qué hace el monitor en cada ejecución
Registrar un monitor con POST /web/uptime recibe una URL objetivo y una cadencia; en cada ejecución realiza una verificación de alcanzabilidad —si el endpoint respondió, su código de estado y cuánto tardó en contestar— y la compara con el estado anterior. Usted decide por completo el intervalo: cada pocos minutos durante una ventana de despliegue, una vez por hora en estado estable, o lo que corresponda al perfil de riesgo del endpoint.
De la alarma de un buscapersonas al monitor programable
Monitorear disponibilidad solía significar que un buscapersonas sonara porque alguien notó que un sitio estaba caído; luego llegaron los tableros y los verificadores externos siempre activos. El siguiente paso es tratar el monitor como un bloque de construcción programable y no como un producto fijo: algo que sus propios sistemas registran, cuya cadencia fijan y que devuelve un webhook cuando el estado cambia, en el horario que su infraestructura realmente necesita y no en el intervalo predeterminado de un proveedor.
Pensado para scripts, no para tableros
Ese diseño encaja de forma natural en un generador de página de estado, en un runbook de respuesta a incidentes o en un pipeline de despliegue que reacciona cuando un monitor se pone en rojo. Registrar el monitor es asíncrono: recibe un schedule_id de inmediato, y a partir de ahí un webhook firmado se dispara cada vez que el estado cambia —la opción práctica para alimentar un sistema de alertas o una página de estado de forma automática— en lugar de consultar un tablero a mano.
Un precio único y predecible
Una verificación fallida se reintenta automáticamente hasta tres veces antes de devolver un error claro, y una tarea que finalmente falla nunca se cobra. Cada verificación cuesta un valor fijo de $0.002 por solicitud, publicado sin niveles ocultos, y no hay plan gratuito ni período de prueba: el acceso requiere saldo prepago, lo que mantiene la capacidad de verificación rápida y libre de abuso.
Casos de integración
Monitoreo de salud tras un despliegue
Registre un monitor sobre un endpoint recién desplegado y reciba un webhook en cuanto deje de responder, para que una regresión aparezca como alerta y no como ticket de soporte.
Monitoreo de infraestructura con intervalo propio
Registre un monitor para cada endpoint crítico con la cadencia que corresponda a su nivel real de riesgo, desde cada pocos minutos hasta una vez al día.
Backend de una página de estado
Alimente una página de estado pública o interna con el webhook que el monitor envía cuando cambia el estado de un endpoint.
Verificación al cerrar un incidente
Mantenga un monitor sobre un endpoint en recuperación y deje que su webhook de recuperación confirme que el servicio volvió antes de cerrar la alerta.
Preguntas técnicas
¿En qué se diferencia esto de un tablero de disponibilidad alojado?
Es un monitor programado, pero el horario es suyo: usted fija la cadencia exacta desde su propia automatización y recibe un webhook solo cuando el estado cambia, en lugar de aceptar el intervalo fijo y el tablero de un proveedor.
¿Qué envía el monitor cuando algo cambia?
Cuando el resultado de una comprobación difiere del anterior, un webhook entrega el cambio —por ejemplo el endpoint pasando de responder a inalcanzable, o un cambio en su código de estado— con el id del monitor y una marca de tiempo.
¿Cómo configuro verificaciones recurrentes de disponibilidad?
Registre el monitor una vez con POST /web/uptime y fije el intervalo cron que quiera; la API sigue ejecutando la comprobación en ese horario por usted, así que no necesita su propio cron para disparar cada verificación.
¿Puedo recibir una alerta cuando una verificación falla?
Sí, configure un webhook firmado y se dispara en cuanto una comprobación detecta que el estado cambió —por ejemplo el endpoint cayendo—, así su sistema de alertas reacciona en la siguiente ejecución programada tras la falla.
¿Puedo monitorear muchos endpoints a la vez?
Sí, registre un monitor por URL y cada uno corre de forma independiente en su propio horario. Para vigilar una lista completa bajo un solo monitor, la versión multi-objetivo encaja mejor.
¿Guardan el histórico de disponibilidad por mí?
No, los resultados se entregan y luego se eliminan tras el período de retención, y nunca se usan para entrenar modelos; construir un historial queda de su lado, normalmente registrando cada resultado de webhook.