Disponibilidad (uptime), SSL y página de estado pública
El seguimiento de excepciones le dice que la aplicación falla; la monitorización de disponibilidad le dice que ya no responde en absoluto. Quiet Guard sondea una URL de su elección, alerta en la transición, guarda un historial de latencia, vigila el certificado TLS y puede compartir todo ello en una página de estado pública.
La sonda activa
Defina una URL a comprobar en los Ajustes del proyecto (sección Monitorización de disponibilidad). Cada cinco minutos, Quiet Guard envía una petición GET:
- Cualquier estado inferior a 400 cuenta como operativo (redirecciones incluidas), con el tiempo de respuesta registrado como latencia.
- Un 4xx/5xx, un timeout (10 s) o un error de conexión cuenta como caída.
- La URL debe ser pública: las direcciones privadas e internas se rechazan con la misma salvaguarda anti-SSRF que los webhooks.
Prefiera un endpoint ligero como la ruta de salud /up de Laravel antes que una página de inicio pesada: usted mide la disponibilidad, no el tiempo de renderizado.
Alertas de caída / recuperación
Las alertas salen en las transiciones, no en cada comprobación fallida: una alerta cuando el sitio cae, una cuando vuelve. Suscriba sus canales a los eventos uptime.down y uptime.recovered en la pestaña Alertas del proyecto (vea Alertas). La protección contra tormentas de alertas se aplica.
Como las sondas pasan cada cinco minutos, una caída más corta que el intervalo entre dos comprobaciones puede pasar desapercibida, la sonda es un detector de humo, no un analizador de paquetes.
Historial de latencia
Cada sonda registra una muestra. El Resumen del proyecto muestra un gráfico de tiempo de respuesta de 24 horas (ventanas de 30 minutos, medias de las comprobaciones exitosas; las ventanas de caída aparecen como huecos, nunca como falsos ceros). Las muestras se conservan siete días, con independencia de la retención de eventos de su plan.
Expiración del certificado TLS
Para las URL https, una tarea diaria lee el certificado directamente en el socket, funciona incluso cuando la cadena está rota, y almacena la fecha de expiración, mostrada en el Resumen del proyecto.
Se le avisa dos veces por certificado: una al bajar de 14 días, una segunda a 3 días (evento ssl.expiring, mismos canales). Un certificado renovado rearma el ciclo. Un certificado ya expirado no necesita ninguna alerta especial: la sonda de los cinco minutos verifica los pares, así que el sitio cae "en avería" y alerta por esa vía.
Expiración del registro del dominio
Un certificado puede renovarse solo; un dominio, no. Una tarea diaria pregunta al registro del dominio, mediante RDAP, cuándo expira su registro, y muestra la fecha en el Resumen del proyecto.
Se le avisa dos veces por dominio: una al bajar de 30 días, una segunda a 7 días (evento domain.expiring, mismos canales), umbrales más amplios que los del certificado, a propósito, ya que renovar un dominio es un pago y no una rotación automatizada. Una renovación rearma el ciclo. Pasada la fecha de expiración, el registro está realmente caducado, lo que registra la pestaña Incidentes del proyecto: un dominio caducado entra en un periodo de recuperación que cuesta una tasa para revertirlo en el registrador.
Cambios en la zona DNS
Una segunda tarea diaria compara la zona, registros A, AAAA, MX, NS y TXT, del host de la URL vigilada con lo observado la última vez. La primera observación sirve de referencia, nunca de alerta; cada cambio posterior dispara dns.changed (mismos canales), nombrando exactamente qué tipos de registro se movieron y sus valores antes y después. Los tiempos de vida (TTL) se ignoran a propósito: cuentan hacia atrás entre dos lecturas de una zona sin cambios y dispararían una alerta en cada pasada. Esto detecta un dominio secuestrado, una configuración de correo rota o una modificación accidental antes de que un cliente se dé cuenta.
Archivos expuestos
Una vez activado desde la pestaña Vulnerabilidades de un proyecto, Quiet Guard pide cada mañana al sitio supervisado una lista cerrada de rutas que nunca deberían responder públicamente. La base es el origen de la URL supervisada (esquema, host, puerto), nunca su ruta.
| Ruta | Lo que da a un desconocido |
|---|---|
/.env, /.env.backup, /.env.production | la configuración, incluido el acceso a la base de datos y APP_KEY |
/.git/config | el repositorio, es decir todo el código fuente y su historial |
/_ignition/health-check | la página de error de desarrollo, crítica si puede ejecutar comandos |
/storage/logs/laravel.log | el registro, con peticiones, direcciones y a veces secretos |
/_debugbar/open | las consultas SQL y las sesiones registradas |
/telescope, /horizon | las peticiones, los jobs, las colas y su contenido |
/phpinfo.php, /info.php | la configuración del servidor y sus variables |
/vendor/composer/installed.json | las versiones exactas instaladas, y por tanto los fallos conocidos |
Una ruta solo se declara expuesta si responde 200 (o 206) y sus primeros bytes se parecen a lo que buscamos: una aplicación de una sola página que devuelve su portada para cualquier dirección desconocida no se señala. Una redirección, un 401, un 403, un 404 o un 410 cuentan como protegidos; cualquier otra respuesta (un límite de tasa 429, un 408, un 5xx) o un error de red no concluye nada, y se conserva el estado conocido.
No se conserva nada de lo que responde el sitio. Quiet Guard lee como máximo 8 KiB, decide en memoria y solo guarda la ruta, el código HTTP y la gravedad. Las peticiones llevan el user agent Quiet Guard-Exposure/1.0, para que pueda reconocerlas en sus registros o autorizarlas en su cortafuegos de aplicaciones.
Una nueva exposición genera el evento exposure.detected (vea Alertas). Una exposición que deja de responder pasa a «Corregido» sin alerta, y vuelve a alertar si reaparece. «Ignorar» silencia un hallazgo deliberado mientras responda.
Para corregirlo: apunte la raíz del servidor web a la carpeta public/ de la aplicación, bloquee las rutas restantes, desactive Ignition, Debugbar y Telescope en producción y cambie cualquier secreto que haya podido leerse. Cerrar el acceso no vuelve secreto lo que ya se leyó.
Active esta búsqueda solo para un sitio que explote su equipo.
Incidentes
La sonda de disponibilidad y la vigilancia del dominio escriben ambas en una pestaña Incidentes compartida en el proyecto: el origen, cuándo comenzó, cuánto ha durado o lleva durando, y una nota que su equipo puede dejar o editar en cualquier momento, resuelto o todavía abierto. En un incidente de disponibilidad, esa nota es lo único de esta pestaña que llega a la página de estado pública de más abajo, junto a la ventana de caída correspondiente, para un lector que nunca tuvo acceso al panel. La nota de un incidente de dominio permanece interna: un registro caducado no es una caída del servicio que informa la página de estado.
La página de estado pública
Active Página de estado pública en los Ajustes del proyecto y comparta el enlace generado, un token no adivinable constituye toda la URL. La página muestra:
- el estado actual y, en caso de caída, desde cuándo;
- la disponibilidad de 7 días: global y en una barra por día;
- la latencia actual y media de 24 horas;
- la fecha de validez del certificado TLS;
- las cinco últimas ventanas de caída, cada una con la nota dejada en su incidente, cuando la haya.
No se expone nada sensible: los visitantes ven el nombre del proyecto y los resultados de la sonda, nunca la URL sondeada, los tokens ni ningún dato de la aplicación. Desactivar la página conserva el token: reactivarla restaura la misma dirección, los enlaces ya compartidos siguen siendo válidos.
Insignia integrable
El mismo token sirve también una insignia SVG plana en /status/{token}/badge.svg: verde con la disponibilidad de 7 días cuando el sitio está en línea, roja "down" durante una caída, gris "n/a" antes de la primera comprobación. Insértela en un README:
El fragmento exacto, con su token real, se muestra bajo el interruptor de la página de estado en los Ajustes del proyecto. La insignia se refresca con la misma caché de un minuto que la página.
Está leyendo la documentación Quiet Guard v1.0.