Un incident ne s’ouvre qu’après deux échecs consécutifs : la vérification échouée est relancée depuis un autre emplacement, ou depuis le même 10 secondes plus tard quand un seul emplacement est en ligne. Donc, si le site fonctionne toujours chez vous, notre vérification et votre navigateur ne voient pas la même chose. L’incident montre ce que la vérification a vu.
Commencez par les preuves
Ouvrez l’incident depuis Incidents. What we saw liste chaque vérification échouée avec son erreur. Pour les sites web, la section affiche aussi :
Connected to et Resolved to : l’adresse IP que nous avons jointe, et ce que le DNS a répondu.Redirected to, le Certificate et les Headers, comme Server, CF-Ray et Retry-After.Start of the response : les 2 premiers Ko envoyés par le serveur. Une page de blocage ou un message d’erreur apparaît ici.Une capture d’écran quand le serveur a répondu, ou le chemin réseau (un traceroute) quand il n’a pas répondu.
La capture d’écran est prise par un vrai navigateur sur un autre réseau. Si elle paraît normale alors que la vérification a échoué, quelque chose traite nos vérifications différemment, souvent une règle de pare-feu.
Causes fréquentes
Un pare-feu ou une protection anti-bots répond HTTP 403, HTTP 429 ou une page de défi comme le « Just a moment… » de Cloudflare. Votre navigateur passe ; une vérification ne peut pas résoudre un défi. Autorisez Uptimecheck dans le pare-feu.Le mot-clé n’est pas dans la page. Les mots-clés sont sensibles à la casse et recherchés dans le HTML envoyé par le serveur : un texte ajouté ensuite par JavaScript n’y figure pas. Choisissez un mot du code source de la page, ou utilisez un parcours dans un vrai navigateur.Les redirections : la vérification en suit jusqu’à 10 et juge la dernière page ; une redirection vers une page de connexion, un mur de cookies ou le site d’un autre pays peut donc faire échouer un mot-clé. Au-delà de 10, vous obtenez Too many redirects.Le code de statut : par défaut, les codes 200 à 399 comptent comme disponibles. Une page censée répondre 401, derrière une connexion, doit avoir ce code dans Expected status codes.Le certificat : un certificat expiré, autosigné ou émis pour un autre nom d’hôte met le moniteur en panne tant que Verify TLS certificate est activé. Un certificat intermédiaire manquant, non : les navigateurs le téléchargent, notre vérification aussi, mais le moniteur affiche Incomplete chain, car certaines applications et certains appareils anciens n’y parviennent pas.Le DNS : après une migration, les résolveurs gardent l’ancienne réponse jusqu’à expiration de son TTL ; nous pouvons donc joindre l’ancien serveur pendant que vous joignez le nouveau, ou l’inverse. Comparez Connected to avec l’adresse de votre serveur. Un nom qui ne se résout qu’à l’intérieur de votre réseau ne peut pas être vérifié depuis l’extérieur, et un nom qui se résout vers une adresse privée est refusé.Les délais d’attente : une vérification attend 10 secondes par défaut (Timeout (s)). Votre navigateur peut afficher une copie en cache, ou celle d’un CDN proche de chez vous, alors que le serveur lui-même est lent.L’emplacement : les vérifications partent de Stockholm, Londres et New York. Un site qui bloque les visiteurs hors de son pays, ou une panne réseau entre l’un de ces emplacements et votre hébergeur, échoue chez nous et pas chez vous. Le chemin réseau montre où les paquets s’arrêtent.Votre propre accès : une adresse IP de bureau autorisée, un VPN, une session connectée ou une entrée dans le fichier hosts peut faire fonctionner le site pour vous seul.
Quand le problème vient de chez nous
Si le réseau de l’un de nos emplacements rencontre un problème, la plupart des sites connus que nous vérifions depuis cet emplacement échouent en même temps. Nous surveillons ce cas et retenons les incidents venant de cet emplacement, pour que vous ne soyez pas alerté à cause de notre problème.
Vérifiez par vous-même
Modifiez le moniteur et utilisez Test request pour envoyer une requête depuis nos serveurs et voir la réponse. Une fois la cause corrigée, deux vérifications réussies d’affilée ferment l’incident. Voir comment fonctionnent les incidents et les preuves, et comment réduire les fausses alertes.