Monitoring de disponibilité, inclus avec vos Core Web Vitals

Le site semble fonctionner et les commandes se sont arrêtées

Le serveur ne répond plus et le CDN continue de servir la page d'accueil en cache. Ou un déploiement casse le checkout sans toucher aux autres pages. Personne ne s'en rend compte avant qu'un client n'envoie un e-mail pour demander pourquoi il ne peut pas payer.

CoreDash surveille les deux pour vous, dans le même projet que vos Core Web Vitals.

Un e-mail et un message Slack quand votre site tombe en panne

Quand votre site tombe en panne ou qu'une page répond avec le mauvais statut, vous recevez un e-mail et un message Slack, puis un autre quand le service est rétabli. Ajoutez les pages qui comptent, à commencer par la page d'accueil et le checkout, et CoreDash vérifie chacune d'elles toutes les 30 minutes.

Un moniteur ne passe à Down qu'après deux échecs consécutifs depuis deux serveurs différents, pour qu'un simple incident réseau ne vous réveille pas.

Tous les sites et toutes les pages que vous surveillez dans une seule liste, avec la disponibilité des 7 derniers jours et les certificats qui expirent sous deux semaines.

Repérez la panne que votre CDN masque

Votre CDN peut continuer de servir des pages en cache alors que votre serveur est en panne. La page d'accueil se charge toujours, mais les clients connectés, les paniers et toutes les pages non mises en cache affichent une erreur. CoreDash passe quand même le site à Down : renseignez l'adresse IP de votre serveur dans les paramètres Avancés lors de l'ajout ou de la modification d'un moniteur, et chaque vérification interroge aussi directement le serveur, en contournant le CDN.

Quelle part de l'attente de vos visiteurs vient du serveur

Dans cet exemple, près de la moitié de l'attente des visiteurs est due au serveur. CoreDash affiche le temps de réponse de chaque vérification à côté du TTFB de vos vrais visiteurs au p75 : environ 950 ms côté sonde, avec un pic chaque soir, contre 1,92 s pour les visiteurs.

L'image ou le titre le plus grand ne peut pas s'afficher avant que le serveur ne réponde : ici, accélérer le LCP commence donc par le serveur.

Repérez le checkout cassé lors du dernier déploiement

Après un déploiement, la page d'accueil peut très bien répondre alors que le checkout affiche « page introuvable » ; un moniteur sur la page d'accueil ne verra rien d'anormal.

Ici, le checkout a son propre moniteur. Il a fonctionné pendant cinq jours, et depuis un déploiement il y a deux jours, il répond 404, ce que CoreDash signale comme Unexpected status. Cela vous envoie là aussi un e-mail et un message Slack, puis un autre dès que le checkout fonctionne de nouveau.

Pas de fausse alerte avec votre pare-feu, et les certificats repérés deux semaines avant d'expirer

Un pare-feu qui bloque la sonde ne déclenche jamais d'alerte de panne. Le moniteur affiche Blocked, renvoie vers la solution et ne compte pas cela comme une indisponibilité.

La liste des moniteurs indique aussi chaque certificat qui expire sous 14 jours. Un renouvellement oublié y apparaît deux semaines avant que les navigateurs ne commencent à avertir vos visiteurs.

Ce qui se passe après un crash à 19:50

Votre serveur cesse de répondre à 19:50. À 20:00, le premier serveur n'obtient pas de réponse et le moniteur passe à Failing ; rien n'est encore envoyé. Une demi-heure plus tard, le second serveur ne reçoit pas de réponse non plus. Le moniteur passe à Down, puis l'e-mail et le message Slack partent.

Dès la première vérification qui reçoit de nouveau une réponse, le moniteur repasse à Up et le message de rétablissement est envoyé de la même façon. Selon le moment où le serveur s'arrête, vous êtes prévenu 30 à 60 minutes plus tard.

L'uptime dans le projet que votre équipe ouvre déjà

Chaque moniteur appartient à un projet CoreDash, et tous les membres du projet le voient à côté du LCP, de l'INP et du CLS du même site. Il est inclus dans votre abonnement actuel et dans l'essai. Demandez à Claude « mon site a-t-il été indisponible cette semaine ? » dans la conversation même où vous lui demandez pourquoi le LCP sur mobile a augmenté. Connectez Claude à CoreDash.

Quand un outil d'uptime dédié est nécessaire

CoreDash effectue une vérification toutes les 30 minutes depuis deux serveurs situés dans une même région et envoie des alertes par e-mail et Slack. Une panne brève entre deux vérifications peut passer inaperçue, et il n'y a ni page de statut publique ni SMS. Pour des vérifications chaque minute depuis de nombreux pays, payer un outil d'uptime dédié se justifie.

Pour vous assurer que votre site et votre checkout fonctionnent, et savoir à quelle vitesse le serveur répond, vous n'en avez pas besoin. Tout est déjà dans votre projet CoreDash, sans aucun surcoût.