Une alerte vous dit que quelque chose ne va pas. C’est là que le vrai travail commence : est-ce vraiment en panne, à quoi ressemble l’erreur, qui s’en occupe, les clients ont-ils été prévenus, et que faut-il changer pour que cela ne se reproduise pas ? Beaucoup d’équipes répondent à ces questions dans trois outils et un long fil de discussion. Uptimecheck garde les réponses avec l’incident.
Des pannes confirmées
Uptimecheck vérifie depuis Stockholm, Londres et New York, et confirme chaque échec depuis un second emplacement avant d’ouvrir un incident. Une requête perdue isolée ne réveille jamais personne. Quand la panne est réelle, l’incident s’ouvre, les alertes partent et la chronologie démarre. Il se ferme tout seul quand le moniteur se rétablit. Notre guide pour réduire les fausses alertes explique pourquoi la confirmation compte.
Les preuves jointes
Ce que nous avons vu : le contrôle en échec, avec l’adresse à laquelle il s’est connecté, les en-têtes et le début de la réponse.Chemin réseau : quand le serveur n’a pas répondu, un traceroute depuis le point de contrôle montre où le chemin se rompt.Capture d’écran : quand le serveur a répondu, un vrai navigateur photographie ce que voyaient les visiteurs. Les captures sont conservées 90 jours.
C’est souvent suffisant pour distinguer un serveur hors service d’un déploiement raté, ou votre problème de celui de votre hébergeur, avant même que quiconque se soit connecté.
Une seule chronologie
La chronologie de l’incident affiche dans l’ordre les contrôles, chaque alerte et les personnes qu’elle a atteintes, les prises en charge et les notes. Acknowledge indique à l’équipe que quelqu’un s’en occupe et annule les alertes différées qui ne sont pas encore parties. Dans Slack, le bouton Acknowledge de l’alerte de panne fait la même chose sans ouvrir l’application. Les notes sont réservées à votre équipe.
03:12 : checkout.northwind.shop renvoie 503, confirmé par un second contrôle. La réponse et une capture d’écran sont jointes.03:13 : notification push à Anna, qui est d’astreinte.03:15 : pris en charge dans Slack.03:19 : rétabli après 7 minutes. Un avis de rétablissement est envoyé.
Escalade et astreinte
Un canal peut attendre de 5 à 60 minutes et n’alerter que si la panne dure toujours et que personne ne l’a prise en charge. Publiez immédiatement dans Slack, et envoyez une notification push à la personne d’astreinte au bout de 10 minutes. Les plannings d’astreinte déterminent de qui il s’agit, et la page alertes et notifications présente tous les canaux.
MTTA et MTTR
La page des incidents affiche le temps moyen de prise en charge (MTTA) et le temps moyen de résolution (MTTR) sur les 30 derniers jours. Ensemble, ils vous disent si les alertes atteignent des personnes capables d’agir, et à quelle vitesse les problèmes sont résolus. Notre article sur MTTR, MTTA et MTBF explique comment les lire.
Dites à vos clients ce qu’il en est
Publiez une mise à jour sur votre page de statut et indiquez pour chaque composant concerné Degraded performance, Partial outage ou Major outage. La page affiche le plus grave entre l’impact que vous indiquez et ce que constatent les contrôles : une mise à jour peut faire paraître un composant plus touché, mais jamais masquer une panne confirmée par les contrôles.
Analyses post-incident
Après un incident, rédigez une courte analyse : ce qui s’est passé, pourquoi, et ce que vous changez. Gardez-la pour l’équipe, ou affichez-la sous l’incident sur votre page de statut. Les clients font davantage confiance à une page qui explique ses pannes qu’à une page qui n’en affiche jamais. Notre modèle de postmortem d’incident vous donne une structure de départ.
Fenêtres de maintenance
Les travaux planifiés ne devraient alerter personne. Pendant une fenêtre de maintenance, les moniteurs choisis ne sont pas vérifiés, aucun incident ne s’ouvre, aucune alerte ne part et ce temps n’est pas décompté de la disponibilité. Les fenêtres peuvent être ponctuelles ou se répéter chaque jour, chaque semaine ou chaque mois ; elles s’affichent sur les pages de statut et peuvent être envoyées par e-mail aux abonnés. Lancez-en une depuis votre script de déploiement via l’API REST.
Les projets évoluent, les fenêtres aussi. Modifiez une fenêtre jusqu’à sa fin : une fenêtre en cours garde son début, mais sa fin, ses moniteurs et son message peuvent changer. Modifiez une série et le changement s’applique à partir de sa prochaine fenêtre, tandis que les fenêtres en cours et passées restent inchangées. Les abonnés informés d’une fenêtre reçoivent un e-mail avec le nouvel horaire, et les rappels d’une série suivent ses nouveaux horaires.
Ouvrez un incident et sa chronologie dans la démo en direct, sans créer de compte. La gestion des incidents est incluse dans toutes les offres.
Les offres commencent à 9 € par mois en facturation annuelle ou 12 € en facturation mensuelle, HT. Consultez la page des tarifs, ou commencez un essai gratuit de 14 jours sans carte bancaire.