Monitorización de sitios web para desarrolladores, integrada en tu stack.
Uptimia ejecuta tus llamadas reales a la API — inicia sesión, obtén el token, haz el pedido, léelo de vuelta — y verifica cada respuesta. Dale a cada cron job una URL de heartbeat, crea monitores desde tu script de despliegue, y recibe avisos en Slack, Discord o PagerDuty.
Step breakdown
All 4 steps passedFailed at step 31.66 s · 14:251.38 s · 14:327-day averagesLast runAssertions — step 3
3 of 3 passing1 of 3 passedResponse — step 3
201 · 624 ms500 · 612 msRecent Runs
every 5 min · 12 locations
New York✗ Failed at step 31.41 s
Frankfurt✗ Failed at step 31.38 s
London✓ All 4 steps passed1.62 s
Sydney✓ All 4 steps passed1.71 sNew York✓ All 4 steps passed1.58 s
Tokyo✓ All 4 steps passed1.64 sCuatro fallos que nunca lanzan una excepción
Los cuatro son ciertos el día del despliegue. Ninguno se mantiene cierto por sí solo — y cuando uno deja de serlo, no salta ninguna excepción.
"Si algo se rompiera, veríamos una excepción."
Los rastreadores de errores solo ven el código que se ejecuta. Una entrada de cron que nunca arranca, un worker atascado a mitad de tarea, un certificado que caduca en silencio — ninguno de ellos lanza una excepción. Los peores fallos no son trazas de pila; son silencio.
"El pipeline está en verde, así que producción está bien."
La CI demuestra que el código estaba bien en el momento del despliegue. Los tokens caducados, los discos llenos, las cuotas agotadas y la configuración que se desvía ocurren entre despliegues — en el sistema en ejecución que tu batería de pruebas nunca vuelve a ver.
"Nos enteraríamos rápido — estamos conectados todo el día."
Estás delante del teclado 40 de las 168 horas de la semana — nadie vigila las otras 128. Y los usuarios rara vez informan de un pago roto; lo intentan una vez más y se van.
"Funcionaba en staging, así que funciona."
Staging nunca tiene el tráfico, el volumen de datos, las cuotas de terceros ni el DNS de producción. Los modos de fallo que te avisan a las 03:00 son precisamente los que staging no puede reproducir.
"Tenemos un endpoint /health, así que estamos cubiertos" es la más grande de todas. Una comprobación de salud cada minuto te dice 1.440 veces al día que un proceso responde (24 × 60). El número de esas comprobaciones que demuestran que el pago se completa, que la copia de seguridad nocturna se ejecutó o que la cola se está vaciando: cero.
"Un proceso responde" y "el sistema funciona" son afirmaciones distintas — y solo una de ellas es la que de verdad les importa a tus usuarios.
Así es como se ve un cron job muerto en silencio cuando hay un heartbeat escuchando.↓ minuto a minuto
Qué ocurre cuando un cron job se detiene en silencio
Un despliegue reescribió el crontab y perdió una línea. Esa noche el worker de facturas no arrancó, no lanzó nada, y todos los paneles se mantuvieron en verde — la cola nunca se movió.
Eso cubre la tarea que murió. Pero cron es solo una de las superficies que fallan sin hacer ruido — cada creencia anterior tiene la suya.↓ un monitor para cada caso
Cadenas, pings y agentes
Cadenas de API para servicios, pings entrantes para tareas, flujos en navegador real para pagos, un agente de una sola línea para la máquina. Superficies distintas, un solo flujo de incidentes, una sola API.
Cadenas, heartbeats y escalados
Llamadas encadenadas, verificadas paso a paso
Un endpoint /health demuestra que un proceso responde. No demuestra nada sobre el flujo que hay detrás. La cadena ejecuta las llamadas reales en orden y comprueba cada respuesta — el código de estado, el tiempo que tardó, un valor dentro del JSON — hasta una vez por minuto en todos los planes de pago, desde todas las ubicaciones o solo las que elijas.
- Hasta 15 pasos — GET, POST, PUT, PATCH, DELETE o HEAD, ejecutados en orden
- Extrae y reutiliza — toma un valor de una respuesta e insértalo en la siguiente con
{{token}} - Verifica lo que importa — código de estado, tiempo de respuesta, un valor JSONPath, una cabecera o texto del cuerpo, por cada paso
/health responde bien durante todo este tiempo — y no demuestra ninguna de estas cuatro llamadas.
0 de 4 verificadas
La tarea que nunca arrancó
Una tarea que deja de ejecutarse se queda en silencio, no en rojo — no lanza ninguna excepción, así que no dispara ninguna alerta. Dale una URL de heartbeat a la que hacer ping cuando se ejecute, y el ping que falta se convierte en la alarma: si se pasa de la ventana más allá del periodo de gracia, Uptimia abre un incidente. Si además señalas el inicio y el final, también detecta tareas que se quedan colgadas en lugar de detenerse.
- Intervalo o calendario cron — un intervalo sencillo o una expresión cron de 5 campos en la zona horaria de tu cuenta
- Una línea para integrarlo — fragmentos listos para copiar y pegar para Crontab, Bash, PowerShell, GitHub Actions y PHP
- Detecta bloqueos, no solo ausencias — envía un ping de inicio y un límite de duración marcará una tarea que nunca termina
Monitores creados desde tu paso de despliegue
Nadie hace clic en nada — el script que publicó el servicio creó su propio monitor. Crea y gestiona monitores a través de la API REST desde un paso de CI, y cuando se abre un incidente, un webhook personalizado lo envía por POST a lo que ya tengas montado: un panel de estado, un bot, un flujo de ChatOps.
- Una API REST — crea, lee, actualiza y elimina monitores en todos los planes (los monitores de API y los heartbeats viven en v2), con claves de API de cuenta gestionadas en los ajustes
- Webhooks personalizados — envía por POST un cuerpo JSON fijo con tus propias cabeceras a cualquier endpoint ante un evento de un monitor
- Seguro por defecto — la entrega del webhook se verifica por TLS, fija el DNS en el momento del envío y rechaza destinos en redes privadas
curl -X POST …/api/v2/api-monitor
-d '{"name":"Checkout API","interval":60}'
Primero Slack, PagerDuty si nadie lo reconoce
En el canal que tu equipo ya vigila, no en una bandeja de entrada que nadie abre de madrugada. El escalado eleva un aviso de Slack sin responder hasta un aviso de PagerDuty según tu calendario, y un solo reconocimiento — pulsado en la propia alerta, sin iniciar sesión — pausa todos los pasos pendientes para todo el mundo.
- Alertas donde trabajas — Slack, Discord, Telegram, MS Teams, Mattermost, PagerDuty, correo electrónico, SMS, webhooks y más
- Escalados por niveles — hasta 10 pasos temporizados por política; reconoce desde la alerta y el escalado se pausa
- Confirmado primero — las interrupciones se verifican desde varias regiones — y las tareas tardías que superan su periodo de gracia — antes de avisar a nadie
Avisado donde ya trabajas, no en otro panel
Un worker que se detuvo, una cadena que se rompió, una máquina sin espacio en disco — todo llega a los mismos canales, y todo es scriptable desde la API REST.
Microsoft TeamsUna sola lista de contactos — configúrala desde la API o desde la interfaz, una vez.
Explora el directorio completo de integraciones →Un despliegue roto debería avisarte a ti.No a tus usuarios.
La prueba de 30 días desbloquea todos los tipos de monitor y todos los canales de alerta.
Configura tu primer monitor en tres pasos
Apúntalo a una superficie, dirige la alerta y déjalo funcionar.
Elige la superficie
Una cadena de API, una URL de heartbeat, un flujo de navegador o el agente de una línea — créalo desde la interfaz o a través de la API REST.
Dirige la alerta
Envíala a Slack, Discord o PagerDuty, añade un webhook, y decide a quién se avisa después si nadie la reconoce.
Déjalo correr
Las comprobaciones se ejecutan desde más de 171 sondas y confirman un fallo antes de avisarte — con el paso o la tarea que falló ya identificados.
También incluido
Agente de servidor de una línea
CPU, memoria, disco y carga desde dentro de la máquina — una instalación en bash verificada por checksum, sin ningún colector que escribir. Linux, mediante un temporizador de systemd o cron.
Monitorización de transacciones
Reproduce un inicio de sesión o un pago en un navegador real — construido paso a paso en el creador, con una captura de lo que vio cada paso.
Ventanas de mantenimiento
¿Vas a desplegar esta noche? Programa la ventana — las comprobaciones se pausan, las alertas se mantienen calladas, sin avisos falsos durante un lanzamiento planeado.
Avisos de recuperación
Cuando un servicio se recupera, las personas a las que se avisó también se enteran — sin ningún «¿sigue caído?» dando vueltas por el canal.
Historial de incidentes
Cada incidente queda registrado con qué se disparó, cuándo, cuánto tardó la recuperación y — cuando hay un escalado en marcha — quién lo reconoció.
Una sola lista para cadenas y tareas
Las cadenas de API, los heartbeats, los servidores y las comprobaciones de disponibilidad comparten un solo panel, una sola columna vertebral de alertas y una sola API — no cuatro herramientas distintas.
¿Qué es la monitorización de sitios web para desarrolladores?
La monitorización de sitios web para desarrolladores es la práctica de vigilar las superficies que publicas — APIs HTTP, tareas en segundo plano, servidores y flujos de usuario — y avisarte a través de las herramientas que ya usas cuando una de ellas se rompe. Integras la monitorización en el stack: una comprobación de API multipaso desde fuera, un ping de heartbeat que envía un cron job, un agente dentro de la máquina, y una API REST y webhooks donde prefieras scriptarlo.
Responde, y aun así está roto
Un ping superficial se mantiene en verde mientras falla el flujo del que dependen tus usuarios.
La cadena lo detecta
La verificación que falla identifica la llamada exacta — así que empiezas a depurar, no a adivinar.
Qué monitor vigila qué
Cada familia vigila una superficie distinta — todas comparten un solo panel, una sola columna vertebral de alertas y una sola API REST. Cada una también se cuenta por separado, y una cadena es la fila más cara de ejecutar — la página de precios recoge las cifras de cada plan.
Ver todos los tipos de monitor →| Superficie | Qué detecta | Cómo funciona |
|---|---|---|
| Cadena de API | Flujos multipaso rotos | Hasta 15 pasos ordenados con verificaciones por paso, comprobados hasta una vez por minuto |
| Heartbeat | Cron jobs y workers que se detienen en silencio | URL de ping entrante; una ventana no cumplida tras el periodo de gracia abre un incidente |
| Disponibilidad | Interrupciones, errores de servidor | Comprobaciones externas hasta cada 30 s en Professional y superiores, confirmadas desde hasta 3 regiones |
| Agente de servidor | Presión de CPU, memoria y disco | Agente Linux de una línea que informa de /proc + df cada 30 s |
| Transacción | Inicios de sesión y pagos rotos | Flujos multipaso reproducidos en un navegador real |
Preguntas frecuentes sobre monitorización para desarrolladores y DevOps
01¿Qué es la monitorización de sitios web para desarrolladores?+
02¿Puedo monitorizar un flujo de API multipaso, no solo un endpoint?+
{{token}}, y verifica el código de estado, el tiempo de respuesta, un valor JSONPath, una cabecera o el texto del cuerpo en cada paso. Si un paso falla, la alerta lo identifica — sabes exactamente qué llamada se rompió.03¿Cómo monitorizo un cron job o un worker en segundo plano?+
curl para que haga ping cada vez que se ejecute. Configura un intervalo o un calendario cron con un periodo de gracia, y si el ping no llega, se abre un incidente. Un ping de inicio junto con un límite de duración también detecta tareas que se quedan colgadas. Hay fragmentos listos para Crontab, Bash, PowerShell, GitHub Actions y PHP.04¿Hay una API de monitorización de disponibilidad para crear y gestionar monitores?+
curl listo para copiar. No hay proveedor de Terraform ni aplicación de Zapier.05¿Puedo emitir una clave de API distinta para cada miembro del equipo?+
06¿A dónde van las alertas, y puedo enviarlas a mis propias herramientas?+
07¿Gestionáis los turnos de guardia?+
08¿El agente de servidor funciona en Windows?+
/proc y df para CPU, memoria, disco y carga. Junto a él se distribuyen un colector en PowerShell para Windows y otro para macOS que envían la misma carga útil — salvo las cifras por núcleo y de espera de E/S que solo expone Linux — pero no se te entregan como una sola línea. Los hosts Windows también se pueden vigilar desde fuera con monitores de disponibilidad, API o transacción.09¿Puedo importar un comando cURL o una especificación OpenAPI en el creador de API?+
10¿Cuántas cadenas, heartbeats y agentes incluye un plan?+
Publícalo. Nosotros lo vigilamos.
Integra una cadena de API, un heartbeat y un agente de servidor en la prueba — las alertas te llegan donde ya estás.