Un incident est l’enregistrement par UptimeWire du fait qu’un site web était hors service : quand cela a commencé, pourquoi, et quand cela a fini. Cette page explique comment un incident s’ouvre, ce que montre sa page et comment il se ferme.
Ce que signifie « hors service »
Pour la vérification de disponibilité, UptimeWire envoie une requête HTTP à votre adresse, suit les redirections et attend jusqu’à 15 secondes une réponse. Une réponse finale de 200 à 399 compte comme correcte. Tout le reste est une vérification échouée. Cela inclut 401 et 403, un délai d’attente dépassé, une connexion refusée, un nom qui ne se résout pas, une erreur de certificat, trop de redirections et une règle de texte de page qui échoue.
Vous pouvez changer les réponses qui comptent comme correctes dans les réglages du site web. Si vous saisissez une liste comme 200-299, 401, seules celles-ci comptent.
Combien d’échecs ouvrent un incident
Une vérification échouée ne crée pas d’incident. Quand une vérification échoue, UptimeWire revérifie après environ 20 secondes. L’incident s’ouvre après trois vérifications échouées de suite.
C’est pourquoi le site web peut d’abord afficher « Vérification en cours ». Ce statut signifie qu’une vérification a échoué et qu’UptimeWire confirme avant de vous prévenir. Aucune alerte n’a été envoyée à ce stade.
Si votre offre inclut plus d’un emplacement de vérification, une vérification compte comme échouée seulement quand plus de la moitié des emplacements qui ont répondu signalent un échec. Une égalité n’est pas une panne.
Le deuxième avis
Quand un seul emplacement a pris part à la vérification, UptimeWire peut demander son point de vue à un second serveur sur un autre réseau avant d’ouvrir l’incident. C’est le « deuxième avis ». Si le second serveur voit le site web fonctionner, l’incident ne s’ouvre pas, ce qui élimine les échecs venant du chemin entre un moniteur et votre site. Si le second serveur est injoignable, l’incident s’ouvre sans lui.
Pourquoi l’alerte arrive après environ une minute
L’alerte attend la confirmation, elle arrive donc plus tard que le premier échec. C’est le prix d’un moindre nombre de fausses alertes. Le délai s’ajoute à votre intervalle de vérification, et plus l’intervalle est court, plus tôt vous êtes prévenu. UptimeWire ne promet pas de délai de détection. La livraison dépend aussi de votre fournisseur de messagerie ou du service récepteur.
La page de l’incident
Ouvrez un incident depuis la liste des incidents, ou depuis le lien d’une alerte. La page montre :
- Durée, Début et Fin. Le début est l’heure de la première vérification échouée des trois. Tant que l’incident est ouvert, Fin indique « Pas encore ».
- Vérifications échouées. Combien de vérifications ont échoué.
- Pourquoi cela a échoué. La raison, avec des conseils. Les raisons courantes sont un délai d’attente dépassé, une connexion refusée, un nom qui ne se résout pas, une erreur de certificat, une réponse hors de la plage correcte et trop de redirections. Lisez ceci en premier : cela désigne généralement la cause.
- Chronologie. La première vérification échouée, le moment où elle a été confirmée, le retour du site web et les alertes envoyées.
- Emplacements. Combien de vérifications ont échoué à chaque emplacement.
- Site maintenant. À quoi ressemble le site web à cet instant.
- Badge de travaux planifiés, si l’incident a commencé pendant une fenêtre de maintenance.
Chaque alerte de la chronologie a un statut, par exemple envoyée, non envoyée, en route, non remise ou retenue jusqu’à la fin des travaux.
UptimeWire conserve le détail des vérifications échouées pendant 90 jours. Ensuite, le résumé de l’incident reste.
Comment un incident se ferme
Un incident se ferme après deux vérifications réussies de suite. UptimeWire envoie alors une alerte de rétablissement par vos canaux. La fin enregistrée de l’incident est l’heure de la première de ces deux vérifications réussies.
Si un site web est mis en pause alors qu’un incident est ouvert, la page indique que la surveillance est en pause et que l’heure de fin n’est pas connue. Un site web en pause n’est pas vérifié du tout, mettez-le donc en pause volontairement.
Travaux planifiés
Pour un travail prévisible, comme un déploiement ou un redémarrage, notez des travaux planifiés pour le site web afin de ne réveiller personne.
- Ouvrez le site web et allez à son onglet « Travaux planifiés ».
- Appuyez sur « Noter des travaux planifiés », puis réglez le début, la fin et une note.
Pendant que le travail est en cours :
- Les vérifications continuent, et les échecs restent dans l’historique.
- Une panne qui commence dans la fenêtre n’est pas comptée comme temps d’arrêt dans votre rapport de SLA ni sur les pages de statut.
- Aucune alerte sur cette panne n’est envoyée, sauf si le site web est toujours hors service à la fin des travaux. S’il l’est encore, les alertes sont envoyées à ce moment. S’il s’est rétabli dans la fenêtre, elles sont abandonnées.
- Les avertissements sur le certificat SSL, le domaine et le DNS ne sont pas retenus.
Il y a des limites. Une fenêtre doit commencer au moins 5 minutes après maintenant et au plus 90 jours à l’avance. Une fenêtre peut durer au plus 24 heures. Un site web peut avoir au plus 48 heures de travaux planifiés par mois civil et au plus 20 fenêtres à venir, et les fenêtres ne peuvent pas se chevaucher. Une fenêtre à venir peut être annulée. Une fenêtre qui a commencé ne peut pas être déplacée, seulement terminée plus tôt avec « Terminer maintenant ».
Une fenêtre notée après le début d’une panne n’excuse pas cette panne.
Pour en savoir plus sur le principe, voir Fenêtre de maintenance et Incident.
Si l’alerte paraît erronée
Lisez la raison sur la page de l’incident. Si le site web fonctionnait pour vos visiteurs, voir Que faire en cas de fausse alerte.