Una incidencia solo se abre cuando fallan dos comprobaciones seguidas: la comprobación fallida se repite desde otra ubicación, o desde el mismo sitio 10 segundos después si solo hay una ubicación activa. Así que, si la web te sigue funcionando, nuestra comprobación y tu navegador están viendo cosas distintas. La incidencia muestra lo que vio la comprobación.
Empieza por las pruebas
Abre la incidencia desde Incidents. What we saw muestra cada comprobación fallida con su error. En las webs también muestra:
Connected to y Resolved to: la dirección IP a la que llegamos y lo que respondió el DNS.Redirected to, el Certificate y Headers como Server, CF-Ray y Retry-After.Start of the response: los primeros 2 kB que envió el servidor. Aquí aparece una página de bloqueo o un mensaje de error.Una captura de pantalla si el servidor respondió, o la ruta de red (un traceroute) si no lo hizo.
La captura la hace un navegador real desde otra red. Si se ve bien aunque la comprobación haya fallado, algo trata nuestras comprobaciones de forma diferente; a menudo, una regla del firewall.
Causas habituales
Un firewall o una protección antibots responde HTTP 403, HTTP 429 o una página de verificación, como el “Just a moment…” de Cloudflare. Tu navegador la supera; una comprobación no puede resolver una verificación. Permite el acceso de Uptimecheck en el firewall.La palabra clave no está en la página. Las palabras clave distinguen mayúsculas y minúsculas y se buscan en el HTML que envía el servidor, así que el texto que JavaScript añade después no está. Elige una palabra del código fuente de la página o usa un flujo en un navegador real.Redirecciones: la comprobación sigue hasta 10 y evalúa la última página, así que una redirección a una página de inicio de sesión, un muro de cookies o la web de otro país puede hacer fallar una palabra clave. Más de 10 da Too many redirects.El código de estado: por defecto, de 200 a 399 cuenta como activo. Una página que debe responder 401, detrás de un inicio de sesión, necesita ese código en Expected status codes.El certificado: un certificado caducado, autofirmado o emitido para otro nombre de host marca el monitor como caído mientras Verify TLS certificate esté activado. Que falte un certificado intermedio no: los navegadores lo descargan, y nuestra comprobación también, pero el monitor muestra Incomplete chain, porque algunas apps y dispositivos antiguos no pueden.DNS: tras una migración, los resolvers guardan la respuesta antigua hasta que caduca su TTL, así que puede que nosotros lleguemos al servidor antiguo y tú al nuevo, o al revés. Compara Connected to con la dirección de tu servidor. Un nombre que solo se resuelve dentro de tu red no se puede comprobar desde fuera, y uno que se resuelve a una dirección privada se rechaza.Tiempos de espera: por defecto, una comprobación espera 10 segundos (Timeout (s)). Puede que tu navegador muestre una copia en caché, o una de un CDN cercano, mientras el propio servidor va lento.Ubicación: las comprobaciones se hacen desde Estocolmo, Londres y Nueva York. Una web que bloquea a los visitantes de fuera de su país, o un fallo de red entre una de esas ubicaciones y tu hosting, falla para nosotros y no para ti. La ruta de red muestra dónde se detienen los paquetes.Tu propio acceso: una IP de oficina permitida, una VPN, una sesión iniciada o una entrada en el archivo hosts pueden hacer que la web solo te funcione a ti.
Cuando el problema es nuestro
Si la red de una de nuestras ubicaciones tiene problemas, la mayoría de las webs conocidas que comprobamos desde ella fallan a la vez. Lo vigilamos y retenemos las incidencias de esa ubicación, para que no te avisemos de un problema nuestro.
Compruébalo tú mismo
Edita el monitor y usa Test request para enviar una petición desde nuestros servidores y ver la respuesta. Una vez solucionada la causa, dos comprobaciones correctas seguidas cierran la incidencia. Consulta cómo funcionan las incidencias y las pruebas y cómo reducir las falsas alertas.