Un tableau de bord de disponibilité et d'incidents doit répondre à trois questions en moins de dix secondes : quelque chose est-il en panne en ce moment, respectons-nous nos objectifs de disponibilité, et quelque chose risque-t-il de tomber bientôt ? Cela suppose une couche supérieure avec l'état, la disponibilité par rapport au SLA, les percentiles de latence et les incidents actifs, complétée par des panneaux d'analyse détaillée qui les expliquent.
Commencer par deux niveaux : vue d'ensemble et analyse détaillée
La plupart des tableaux de bord échouent parce qu'ils donnent le même poids à chaque panneau. Séparez la vue qu'un ingénieur d'astreinte ouvre lors d'une alerte de celle qu'un responsable d'équipe consulte chaque semaine.
- Vue d'ensemble : état actuel, pourcentage de disponibilité par rapport à l'objectif, tendance du temps de réponse et incidents ouverts. Ces panneaux doivent être visibles sans faire défiler la page.
- Analyse détaillée : répartition des erreurs et des codes de statut, disponibilité par région, historique MTTD/MTTR, expiration des certificats et des domaines, et volume d'alertes par moniteur. Ils expliquent pourquoi la couche supérieure présente cet aspect.
Les panneaux de vue d'ensemble
Aperçu de l'état actuel
Une ligne par service indiquant s'il est opérationnel, dégradé ou en panne, avec les services défaillants en tête de liste. Affichez l'heure du dernier changement d'état : « en panne depuis 40 secondes » et « en panne depuis 40 minutes » appellent des réponses très différentes.
Pourcentage de disponibilité par rapport à l'objectif SLA
Affichez la disponibilité de chaque service sur 24 heures, 7 jours et 30 jours avec une ligne de référence SLA. Un objectif mensuel de 99,9 % autorise environ 43 minutes d'indisponibilité ; afficher le budget d'erreur restant en minutes est donc souvent plus utile que le pourcentage. La vue sur 30 jours indique si vous pouvez vous permettre un déploiement risqué.
Tendance du temps de réponse avec p50 et p95
Les moyennes masquent les problèmes. Tracez la médiane (p50) pour l'expérience typique et le p95 pour vos utilisateurs les plus lents. Un p50 stable avec un p95 en hausse signale souvent une dépendance saturée ou une région dégradée avant une panne complète.
Incidents actifs et récents
Listez les incidents ouverts avec leur heure de début, les moniteurs concernés et leur durée en cours, puis les incidents résolus au cours des 72 dernières heures. La durée compte davantage que le nombre.
Les panneaux d'analyse détaillée
- MTTD et MTTR : le temps moyen de détection indique si les intervalles de vérification et les seuils sont suffisamment serrés ; le temps moyen de résolution mesure l'efficacité de la réponse. Suivez leur tendance sur 30 à 90 jours.
- Taux d'erreur et répartition des codes de statut : répartissez les réponses en 2xx, 3xx, 4xx et 5xx. Un pic de 5xx pointe vers le serveur ; une hausse des 404 après une mise en production signale généralement des routes cassées.
- Compte à rebours d'expiration SSL et domaine : affichez les jours restants pour chaque certificat et chaque domaine, avec des avertissements à 30, 14 et 7 jours. Les pannes liées à une expiration sont entièrement évitables.
- Disponibilité par région : des vérifications depuis plusieurs emplacements distinguent une panne globale d'un problème régional de DNS, de CDN ou de routage.
- Volume d'alertes : comptez les alertes par moniteur et par semaine. Les moniteurs qui se déclenchent souvent sans incident correspondant doivent être réajustés.
Panneaux et fenêtres temporelles recommandés
| Panneau | Question à laquelle il répond | Fenêtre temporelle recommandée |
|---|---|---|
| État actuel | Qu'est-ce qui est en panne en ce moment ? | En direct |
| Disponibilité vs SLA | Respectons-nous notre objectif de disponibilité ? | 24 h / 7 j / 30 j |
| Temps de réponse p50/p95 | Les performances se dégradent-elles pour les vrais utilisateurs ? | 24 h, comparé à 7 j |
| Incidents actifs et récents | Qu'est-ce qui est ouvert et depuis combien de temps ? | En direct + 72 h |
| MTTD / MTTR | Détectons-nous et corrigeons-nous plus vite ? | 30–90 j |
| Répartition des codes de statut | La panne vient-elle du serveur ou du client ? | 24 h / 7 j |
| Expiration SSL et domaine | Qu'est-ce qui va expirer sans que nous le remarquions ? | 30–90 prochains jours |
| Disponibilité par région | Le problème est-il global ou régional ? | 24 h |
| Volume d'alertes | Quels moniteurs génèrent du bruit ? | 7 j / 30 j |
Pour savoir quelles métriques prioriser en premier, consultez notre guide sur les métriques de disponibilité de site web que les équipes SaaS doivent suivre en priorité.
Comment UpScanX couvre ces panneaux
UpScanX fournit pour chaque moniteur une vue des performances en temps réel avec l'état actuel, le pourcentage de disponibilité, l'historique des temps de réponse et le nombre d'incidents, pour les vérifications HTTP/HTTPS, API, SSL, domaine, ping et port exécutées depuis plus de 15 emplacements dans le monde. Les alertes sont envoyées par e-mail, Slack, Telegram, Microsoft Teams ou Webhook, et les rapports IA ajoutent la détection d'anomalies, la corrélation d'alertes et des synthèses planifiées par e-mail.
Côté trafic, le tableau de bord analytique UpScanX gratuit ajoute une répartition des codes de statut HTTP (2xx/3xx/4xx/5xx et pages d'erreur) issue de visites réelles, pour voir si un incident a réellement touché les utilisateurs.
Points clés à retenir
- Séparez les panneaux de vue d'ensemble (état, disponibilité vs SLA, p50/p95, incidents ouverts) des panneaux d'analyse détaillée.
- Affichez la disponibilité sur 24 h, 7 jours et 30 jours avec une ligne SLA et un budget d'erreur visibles.
- Utilisez des percentiles, et non des moyennes, pour le temps de réponse.
- Suivez les comptes à rebours d'expiration et la disponibilité par région pour détecter les pannes évitables et partielles.
- Examinez chaque mois le MTTD, le MTTR et le volume d'alertes.