Sin beneficios vagos — solo la mecánica real. Sacada directamente del código que corre en producción.
Uptime, SSL y salud de la página principal están conectados para que veas la causa, no solo el síntoma.
HTTP/HTTPS en los intervalos que marca tu plan. Timeout por sitio, código HTTP esperado, opción de seguir redirecciones, opción de verificar SSL. Tiempo de respuesta registrado al milisegundo. Cuerpo de respuesta limitado a 1 MB para que una respuesta gigante mal configurada no rompa un chequeo.
Emisor, CN del sujeto, lista SAN, valid-from / valid-to, días hasta caducar, coincidencia de hostname (con wildcard), detección de certificados autofirmados o aún no válidos. Alertas escalonadas a 30, 14, 7 y 3 días. Cada nivel se envía una sola vez — sin emails repetitivos.
Title, meta description, h1, canonical, directiva noindex, robots.txt, sitemap.xml — comprobados a diario. Más clasificación de integridad: los PHP fatals, las páginas de crash de framework y los errores de base de datos se reconocen como incidencias de backend, no como problemas de SEO.
Cuando un chequeo es bloqueado por el challenge anti-bots de Cloudflare, Monitrova lo notifica explícitamente como "bloqueado por protección anti-bots" en lugar de decirte que tu sitio sano está caído. Se acabaron las falsas caídas provocadas por tu propio WAF.
Si los últimos 5 chequeos exitosos han superado los 5 segundos, el sitio se marca para el operador sin disparar una alerta de caída. Detecta la degradación progresiva antes de que la noten tus clientes.
Pon cualquier URL HTTPS de webhook en la configuración del sitio. Cada alerta y recuperación dispara un POST JSON: sitio, tipo de alerta, severidad, asunto, timestamp, enlace al incidente. Campo text compatible con Slack en el nivel superior para una integración inmediata.
Esto es lo que la mayoría de monitores no tienen. Cada decisión sobre una alerta pasa por un servicio que sabe diferenciar entre un fallo puntual y un problema real.
Incidencias no críticas — canonical ausente, 503 puntual, glitch transitorio en el handshake SSL — abren una incidencia sospechosa. Aún sin email. El siguiente escaneo confirma (y dispara la alerta) o la cierra en silencio (sin email alguno). Los fallos puntuales no llegan nunca a tu bandeja.
Las incidencias críticas saltan la confirmación — sitio caído, SSL inválido, noindex en la página principal, error de backend. Email de inmediato.
Cuando la misma combinación (sitio, problema) se abre y se recupera tres o más veces en 24 horas, las alertas individuales paran y se activa un único resumen diario. Paquete por sitio: conteo de fallos, conteo de recuperaciones, primer/último visto, IDs de incidencias relacionadas, lista de causas probables.
Los errores de backend van primero; los fallos de SEO aparecen como (probablemente derivados de [primaria]).
Aunque una incidencia siga dando guerra, la frecuencia de alertas se dobla en cada repetición (con tope de 24h). Una caída larga no se traduce en un email cada 60 segundos.
Si la alerta original se retuvo — por el motivo que sea: cooldown, sospechosa, resumen de oscilación, horas tranquilas — la recuperación correspondiente también se suprime. Nunca recibirás "¡buenas noticias, tu sitio ha vuelto!" por una caída de la que no te avisamos.
Por cuenta, con conciencia de zona horaria IANA. Las alertas no críticas se retienen dentro de la franja — caída del sitio, SSL inválido y noindex sí pasan. Los valores por defecto dependen del tipo de cuenta: operadores en solitario tienen el envío de recuperaciones activado; las agencias lo tienen desactivado.
Estricta, estándar o silenciosa — se configura por sitio. Multiplica la ventana de cooldown. Permite a las agencias ajustar clientes ruidosos sin afectar al resto de su cartera.
Cada resultado de chequeo pasa por un clasificador por precedencia con categorías ponderadas. Gana el problema de mayor prioridad; los problemas derivados se listan explícitamente como suprimidos.
| transport | 100 | DNS · connection refused · timeout |
| cf_challenge | 95 | Cloudflare bot-challenge response |
| ssl | 90 | Invalid · expired · hostname mismatch |
| http_availability | 80 | Unexpected status (got 500, expected 200) |
| backend | 70 | Database error · PHP fatal · framework crash |
| rendering | 60 | Blank or partial output |
| seo | 30 | Title · meta · h1 · canonical · robots · sitemap |
| healthy | 0 | All checks passed |
Por eso una página principal que devuelve "Error establishing a database connection" dispara un incidente de backend — no tres avisos de "falta meta tag".
Enviada, suprimida, aplazada o resumida — con el motivo. Visible en la UI junto al asunto del email, el destinatario y el ID del mensaje del proveedor.
El email llegó al servidor SMTP (o a la API de Mailgun). Se captura el ID de mensaje de Mailgun y el estado HTTP.
El servicio de decisión la descartó. Motivo: cooldown, awaiting confirmation, recovery_no_original o preference_disabled.
El primer escaneo fallido abrió una incidencia sospechosa. Esperando al segundo escaneo para confirmar o cerrar.
El sitio está oscilando. Plegada en el resumen diario en lugar de enviarse individualmente.
Generado el día 1 de cada mes. Por sitio: % de uptime, total de chequeos, tiempo de respuesta medio + percentil 95, cronología de incidencias, snapshot de SSL, estado de la página principal. Renderizado desde el histórico guardado — sin chequeos en vivo al generar el informe.
Solo se envía cuando un sitio está oscilando; si no, silencio total. Agrupa conteos de fallos/recuperaciones por tipo, primer/último visto y una lista de causas probables. Errores de backend primero; los fallos de SEO se muestran como síntomas derivados.
El plan gratuito cubre un sitio para siempre. Añade una URL y el primer chequeo de uptime se dispara en pocos minutos.