Migrar desde UptimeRobot a StatusInspector
Si ya usas UptimeRobot, Better Stack, Pingdom o similar, probablemente no buscas “otro ping”: buscas menos ruido, mejor contrato de API y una forma clara de comunicar estado a clientes. StatusInspector encaja en ese espacio: monitores sintéticos (HTTP, TCP, DNS, SSL, ICMP según despliegue), modo API con assertions JSON en planes que lo incluyen, incidentes y páginas de estado públicas.
Esta guía no sustituye la documentación legal de terceros; sirve para planificar una migración por fases sin doble facturación eterna ni alertas duplicadas.
Por qué plantear el cambio (sin hype)
- Un código 200 no garantiza que tu API devuelva datos válidos; las assertions JSON permiten fijar expectativas sobre el cuerpo (según plan).
- Multi-región con confirmación ayuda a distinguir un fallo local de red de un incidente real (según plan y máximo de probes por check).
- API pública para automatizar monitores e integraciones (habilitada en planes Pro y Enterprise, no en Free según el catálogo actual).
Compara siempre el precio, soporte y roadmap de tu proveedor actual con los límites publicados en StatusInspector para tu cuenta.
Tabla de equivalencias (orientativa)
| Concepto habitual (p. ej. UptimeRobot) | En StatusInspector | Notas |
|---|---|---|
| Monitor HTTP(s) | Monitor HTTP / Web | Códigos esperados, keyword, modo navegador vs API |
| Monitor de palabra clave / keyword | Keyword en respuesta | En modo web o según configuración del check |
| Monitor de puerto | Monitor TCP | Host + puerto |
| Monitor DNS | Monitor DNS | Registros según tipos soportados |
| Monitor de ping | Tipo ping / ICMP | Depende de que el worker/probe permita ICMP saliente |
| Heartbeat / cron | Monitor Heartbeat | Push a URL con token; suele estar en planes de pago en el catálogo actual |
| Intervalo mínimo | Intervalo mínimo por plan | Free 5 min; Pro 1 min; Enterprise 30 s |
| “Locations” / regiones | Multi-región / probes | Máximo de probes por check: Free 1, Pro 3, Enterprise 5 |
| Integraciones (Slack, etc.) | Canales de notificación | Configura canales y reglas en la cuenta |
| Status page | Página de estado pública | Cuota de páginas según plan |
| API para automatizar | /api/v1 con token Bearer | No incluida en Free |
| Assertions JSON en API | Reglas con operadores (exists, equals, gt…) | No en Free; disponible en Pro y Enterprise |
Los números exactos de cuotas (monitores, canales, miembros) dependen de tu plan; consulta la página Planes y límites para ver los valores actuales.
Comparativa directa (matriz mental)
| Dimensión | UptimeRobot (típico) | StatusInspector |
|---|---|---|
| Alcance principal | Muchos monitores, simplicidad | Contrato HTTP/API + incidentes + estado |
| API REST rica | Variable | CRUD de monitores, lectura de checks e incidentes (según plan) |
| Assertions JSON avanzadas | A menudo limitadas o vía keyword | Reglas ordenadas con operadores (exists, equals, gt, …) en planes con feature |
| Multi-región | Varias ubicaciones de check | Hub con confirmación por probes bajo demanda (cuando aplica) |
| Heartbeat | Sí (producto maduro) | Sí; atención a gating por plan |
Tutorial paso a paso (migración en paralelo)
1) Inventario en el proveedor actual
Exporta o anota, por cada monitor: URL o host, tipo (HTTP, port, ping…), intervalo, timeout, códigos esperados, keyword, integraciones conectadas y umbrales de alerta (si existen).
2) Crea la estructura en StatusInspector
- Crea canales de notificación (email, Slack, Discord, webhook) antes de activar tráfico productivo.
- Crea grupos o páginas de estado si las usas en el proveedor antiguo, para mapear 1:1 la narrativa a clientes.
3) Reproduce los monitores (empieza por los críticos)
- Sitio web estático o landing: monitor HTTP con código 200 y keyword opcional.
- API REST: activa el modo API, método y cabeceras; si tu plan incluye assertions, añade 1–3 reglas que describan un “health” real (no solo 200). Ver Monitoreo de API y assertions JSON.
- Jobs por cron: evalúa un Heartbeat con token dedicado (si tu plan lo permite) frente a un check HTTP que no ve el batch interno.
- Puerto y DNS: equivalentes directos con los tipos TCP y DNS.
4) Duplica canales y reduce ruido
Configura intervalo, timeout y (si tu plan incluye varios probes) revisa cómo el consenso cambia la sensibilidad frente a un solo punto de observación; al inicio de la migración suele ayudar ser algo más conservador que en el proveedor anterior.
5) Prueba y compara
Usa el “Ejecutar check” manual y revisa el historial de checks e incidentes durante 24–72 h. Ajusta timeouts y reglas JSON antes de apagar el proveedor antiguo.
6) Cambia DNS o enlaces de status page
Cuando la paridad te convenza, actualiza enlaces en la web, documentación y firmas (status page, webhooks) y pausa o cancela los monitores duplicados en el proveedor previo.
Sobre la API pública y el plan Free
En el plan Free, el acceso a la API pública está deshabilitado: la automatización vía /api/v1 requiere un plan Pro o Enterprise. Si tu migración depende de Infrastructure as code o pipelines que crean monitores por API, planifica el plan adecuado antes de cortar el servicio anterior.
Dónde continuar
- Monitoreo de API
- Canales de notificación
- Umbrales y reglas
- Páginas de estado
- Autenticación de la API
Los nombres comerciales de terceros (p. ej. UptimeRobot) son marcas de sus titulares; se citan solo para orientar la migración.