Surveiller son site web gratuitement : être alerté dès qu'il tombe

Pourquoi surveiller ton site de l'extérieur

Un site en panne ne prévient personne. Il n'envoie pas d'email, il ne sonne pas. Il affiche une erreur à chaque visiteur, en silence, jusqu'à ce que quelqu'un s'en rende compte et prenne la peine de te le dire. Pour un site vitrine, c'est un prospect qui repart chez un concurrent. Pour une boutique en ligne, ce sont des commandes qui ne passent pas. Pour une agence ou un freelance, c'est le client qui appelle : « Tu savais que mon site ne marchait plus ? ». Et la réponse est toujours un peu gênante.

On pourrait croire que l'hébergeur s'en charge. En partie seulement. Ton hébergeur surveille ses machines : si le serveur physique tombe, il le voit. Mais un site peut être en panne sur un serveur parfaitement en forme : une extension qui plante après une mise à jour, une base de données saturée, un certificat HTTPS expiré, un nom de domaine qui n'a pas été renouvelé, un DNS mal modifié. Du point de vue de l'hébergeur, tout va bien. Du point de vue de tes visiteurs, le site n'existe plus.

C'est pour ça que la surveillance doit se faire de l'extérieur, en se mettant à la place d'un visiteur : un service, installé ailleurs que ton site, qui ouvre régulièrement ta page comme le ferait un navigateur et qui te prévient quand la réponse n'est pas la bonne. On parle de monitoring uptime, ou de surveillance de disponibilité. Le principe est simple, et on peut le mettre en place gratuitement. Le diable est dans les détails : ce qu'on vérifie exactement, à quel rythme, et qui reçoit l'alerte.

Ce qu'une vérification HTTP contrôle vraiment

Une vérification (on dit aussi un check) consiste à envoyer une requête à l'adresse de ton site et à examiner la réponse. Selon les outils, on y regarde plus ou moins de choses. Voici celles qui comptent.

Le code de réponse HTTP

Chaque réponse d'un serveur web commence par un code à trois chiffres. C'est le premier indice, et souvent le plus fiable :

• 2xx (le plus courant : 200) : la page a été servie normalement.
• 3xx (301, 302…) : redirection vers une autre adresse, par exemple de http:// vers https://, ou de monsite.fr vers www.monsite.fr.
• 4xx (404, 403…) : la page demandée n'existe pas ou l'accès est refusé. Sur ta page d'accueil, c'est presque toujours un problème.
• 5xx (500, 502, 503…) : erreur côté serveur. Le site est cassé.

Une bonne vérification suit les redirections jusqu'à la page finale, puis juge le code de cette page. Un 301 vers ta page d'accueil n'est pas une panne ; un 301 qui mène à une erreur 500, si.

Le délai de réponse

Un serveur qui ne répond pas du tout est en panne, même s'il ne renvoie aucune erreur. Les outils fixent donc un délai maximum (souvent une dizaine de secondes) au-delà duquel la vérification échoue. Entre les deux, il y a la zone grise : un site qui répond, mais en six secondes au lieu d'une. Techniquement, il est en ligne. En pratique, tes visiteurs partent. Certains outils permettent de fixer un seuil de lenteur pour être prévenu de ce genre de ralentissement sans le compter comme une panne.

Le certificat HTTPS

Si le certificat de ton site a expiré ou n'est pas valide, les navigateurs affichent une grosse page d'avertissement, et la plupart des visiteurs n'iront pas plus loin. Une vérification sérieuse refuse elle aussi un certificat invalide, et considère le site comme en panne. Mieux encore : être prévenu avant l'expiration, quand il reste quelques jours pour corriger.

Le contenu de la page

C'est le niveau au-dessus : vérifier qu'un mot précis est présent dans la page (le nom de ta marque, « Ajouter au panier »), ou qu'un message d'erreur en est absent. C'est ce qui permet de repérer les pannes « déguisées », dont on parle juste en dessous.

Les pièges : fausses alertes et fausses bonnes nouvelles

Une surveillance mal réglée a deux façons d'échouer. Soit elle crie au loup, et tu finis par ignorer ses alertes. Soit elle reste verte pendant que ton site est cassé, et tu te crois protégé. Les deux sont aussi dangereuses.

Le site « en ligne » qui affiche une erreur

Certains sites, en panne, renvoient quand même un code 200 : une page blanche, un message « Maintenance en cours » oublié, une page d'erreur personnalisée servie comme une page normale, ou une page d'accueil mise en cache qui s'affiche alors que tout le reste (connexion, panier, formulaire) est cassé. Pour une vérification qui ne regarde que le code, tout va bien.

Deux parades. La première, c'est la vérification de contenu (un mot-clé attendu dans la page). La seconde, souvent plus robuste si tu as la main sur le code : créer une adresse dédiée, par exemple /health, qui teste vraiment ce qui compte (la connexion à la base de données, par exemple) et renvoie une erreur 500 si quelque chose ne va pas. Tu surveilles alors cette adresse plutôt que la page d'accueil.

Ne surveiller que la page d'accueil

La page d'accueil est souvent la page la plus simple et la plus mise en cache de ton site. C'est aussi celle qui tombe en dernier. Si ton activité repose sur autre chose (le tunnel de commande, l'espace client, le formulaire de contact, une API), surveille aussi cette partie-là.

Le blocage par un pare-feu

Les pare-feu applicatifs et les protections anti-robots peuvent bloquer les requêtes de l'outil de surveillance, qui vient d'un serveur et pas d'un navigateur. Résultat : des fausses alertes, parfois une seule de temps en temps, parfois en continu. Si ça arrive, autorise l'adresse IP de l'outil dans ton pare-feu. Les services sérieux publient la liste des adresses depuis lesquelles partent leurs vérifications.

Les coupures réseau d'une seconde

Internet n'est pas parfait. Une requête isolée peut échouer pour une raison qui n'a rien à voir avec ton site : un paquet perdu, un routeur qui hoquette. Alerter dès le premier échec produit du bruit. Les bons outils refont un essai quelques secondes plus tard avant de déclarer la panne. À l'inverse, attendre cinq échecs de suite avant d'alerter, c'est rater les pannes courtes et découvrir les longues trop tard.

Les méthodes gratuites, et leurs limites

Le script maison : curl et cron

Si tu as un serveur sous Linux, tu peux écrire ta propre surveillance en quelques lignes. Ce script récupère le code de la page finale (après redirections), avec un délai maximum de 10 secondes, et envoie un email si le code n'est pas bon :

#!/bin/sh
# /usr/local/bin/check-site.sh
URL="https://www.monsite.fr/"
CODE=$(curl -s -L -o /dev/null -w '%{http_code}' --max-time 10 "$URL")

# curl renvoie 000 si le site ne répond pas du tout
if [ "$CODE" -lt 200 ] || [ "$CODE" -ge 400 ]; then
  echo "$URL a répondu $CODE à $(date '+%H:%M')" \
    | mail -s "ALERTE : $URL ne répond plus" [email protected]
fi

Puis dans ta crontab, pour le lancer toutes les 5 minutes :

*/5 * * * * /usr/local/bin/check-site.sh

C'est gratuit, et c'est un excellent exercice pour comprendre ce que fait un outil de surveillance. Mais en usage réel, les limites arrivent vite :

• Si le script tourne sur le même serveur que le site, il tombe avec lui. Serveur éteint, plus de script, plus d'alerte. Il faut donc une deuxième machine, qui peut elle-même tomber sans que tu le saches.
• L'envoi d'email depuis un serveur demande une configuration (la commande mail doit pouvoir envoyer), et ces emails finissent souvent en spam.
• Pas de mémoire : tant que le site est en panne, tu reçois un email toutes les 5 minutes. Et rien ne te dit quand il revient.
• Pas de nouvel essai : la moindre coupure réseau déclenche une alerte.
• Pas d'historique : impossible de dire combien de temps le site a été indisponible le mois dernier.

Tu peux tout ajouter, bien sûr. Mais à ce stade, tu es en train de réécrire un outil de surveillance, et de devoir le surveiller lui aussi.

Google Search Console : utile, mais pas pour ça

Search Console signale des problèmes rencontrés par Google en explorant ton site, y compris des erreurs serveur. C'est précieux pour le référencement, mais ce n'est pas une surveillance de disponibilité : Google explore ton site à son rythme, pas toutes les quelques minutes, et ses rapports ne sont pas faits pour te prévenir dans le quart d'heure qui suit une panne. Garde-le pour ce qu'il fait bien, et ne compte pas sur lui pour savoir que ton site est tombé ce matin.

Les services de surveillance avec une offre gratuite

C'est la solution la plus simple : un service externe fait les vérifications, garde l'historique, gère les nouveaux essais et t'envoie une alerte à la panne puis au retour. Plusieurs services ont une offre gratuite, avec des limites différentes. Voici les principaux, avec leurs offres gratuites telles qu'affichées sur leurs sites en septembre 2026 (elles changent régulièrement, vérifie avant de choisir) :

Pour être clair : en nombre de monitors et en fréquence, UptimeRobot et Better Stack sont plus généreux que Pinguro en gratuit. Si tu dois surveiller vingt sites toutes les cinq minutes sans rien payer, ce sont de bons choix. Uptime Kuma est différent : c'est un logiciel libre que tu installes toi-même. Il est très complet, mais il faut un serveur pour l'héberger, le maintenir à jour, et le placer ailleurs que les sites qu'il surveille, sinon on retombe sur la limite du script maison.

Pinguro vise autre chose : un outil en français, hébergé en France (serveur et base de données chez OVHcloud), simple à prendre en main, avec une page de statut publique et les fenêtres de maintenance incluses dès le plan gratuit. Pour surveiller ton site principal, ton espace client et une tâche planifiée, les 3 monitors suffisent. Au-delà, il faudra attendre les plans payants, qui ne sont pas encore ouverts.

Quel intervalle de vérification choisir

L'intervalle, c'est le temps entre deux vérifications. C'est aussi, dans le pire des cas, le temps qu'il faut pour découvrir une panne : si ton site tombe juste après une vérification, la suivante le verra un intervalle plus tard.

• 1 minute : pour ce qui coûte de l'argent à chaque minute de panne (une boutique à fort trafic, une API dont dépendent des clients). C'est rarement disponible gratuitement.
• 3 à 5 minutes : un bon compromis pour la plupart des sites professionnels.
• 15 minutes : suffisant pour un site vitrine, un blog, un site de présentation. Une panne peut passer inaperçue un quart d'heure, mais tu la connais bien avant ton client, qui, lui, la découvre souvent le lendemain.

Une vérification toutes les 15 minutes ne rattrape pas une panne de 3 minutes qui tombe entre deux passages. Ce n'est pas grave pour la plupart des sites : les pannes qui font vraiment mal sont celles qui durent. Et une surveillance toutes les 15 minutes vaut infiniment mieux que pas de surveillance du tout.

À qui envoyer l'alerte

Une alerte n'a de valeur que si quelqu'un la lit à temps. Quelques règles simples :

• Une adresse que tu lis vraiment, avec les notifications activées sur ton téléphone. Pas l'adresse contact@ qui reçoit cinquante newsletters par jour.
• La personne qui peut agir. Si c'est ton prestataire qui gère le serveur, il doit recevoir l'alerte, pas seulement toi.
• Un filtre dans ta messagerie qui met les alertes en évidence (étiquette, notification prioritaire) pour qu'elles ne se noient pas.
• Pas trop de monde. Une alerte envoyée à dix personnes est souvent traitée par personne, chacun pensant qu'un autre s'en occupe. Décide qui est responsable.
• Teste la chaîne une fois, en déclenchant une vraie alerte : c'est le seul moyen de vérifier que l'email n'arrive pas dans les spams.

Pour une agence, faut-il prévenir le client directement ? Souvent, mieux vaut recevoir l'alerte soi-même, vérifier, puis prévenir le client avec un message qui dit que c'est pris en charge. Une page de statut, qu'on voit plus bas, fait très bien ce travail.

L'alerte arrive : la checklist des premières minutes

Le jour où l'alerte tombe, tu n'auras pas envie de réfléchir à une méthode. Garde cette liste sous la main :

1. Confirme la panne depuis un autre réseau. Ouvre ton site depuis ton téléphone en 4G/5G, Wi-Fi coupé, ou vérifie-le avec l'outil gratuit Site en panne ?. Ça élimine un problème de cache ou de connexion chez toi.
2. Lis la raison de l'alerte. Une erreur 5xx pointe vers le serveur ou l'application, un délai dépassé vers un serveur surchargé ou bloqué, une erreur DNS vers le nom de domaine, une erreur de certificat vers le HTTPS. Ça te dit où chercher.
3. Regarde la page de statut de ton hébergeur (et de ton CDN si tu en as un). Si la panne est chez eux, tu n'as rien à réparer, seulement à informer.
4. Demande-toi ce qui a changé récemment. Une mise à jour d'extension, un déploiement, une modification DNS, un renouvellement de certificat ou de nom de domaine arrivé à échéance. La plupart des pannes suivent un changement.
5. Vérifie les causes classiques : espace disque plein, base de données arrêtée, quota de l'hébergement dépassé, nom de domaine expiré.
6. Préviens tes clients si la panne dure plus de quelques minutes : un message court, qui dit ce qui ne marche pas et quand tu donneras des nouvelles.
7. Après le retour à la normale, note en deux lignes ce qui s'est passé et ce que tu changes pour éviter que ça recommence.

Prévenir tes clients : la page de statut

Pendant une panne, chaque client qui ne sait pas ce qui se passe t'écrit ou t'appelle, au moment où tu devrais réparer. Une page de statut publique répond à leur place : elle affiche l'état de tes services, les incidents en cours et tes messages. Elle doit être hébergée ailleurs que ton site, pour rester accessible quand il tombe, et alimentée par la surveillance, pour passer au rouge toute seule.

Ce qu'elle doit afficher et comment écrire un message d'incident qui rassure sont détaillés dans le guide Status page publique : ce que tes clients attendent vraiment, avec trois modèles de messages prêts à l'emploi.

Surveiller ton site gratuitement avec Pinguro, pas à pas

Voici la mise en place complète avec le plan gratuit de Pinguro. Compte cinq minutes.

1. Crée ton compte

Sur pinguro.app/dashboard, ouvre l'onglet Inscription, saisis ton email et un mot de passe (8 caractères minimum), puis clique sur Créer mon compte. Tu reçois un email de vérification : clique sur le lien, puis connecte-toi. Pas de carte bancaire, pas d'essai limité dans le temps.

2. Ajoute ton site

Dans Monitors, clique sur + Ajouter un monitor. Le type HTTP / HTTPS est sélectionné par défaut. Remplis :

• Nom : un nom clair, par exemple « Site vitrine » ou « Boutique ». C'est lui qui apparaîtra dans les alertes et sur ta page de statut.
• URL complète, avec https:// : ta page d'accueil, ou mieux, la page qui compte vraiment pour ton activité.
• Intervalle : 15 minutes sur le plan gratuit (laisse la valeur par défaut).

Clique sur Ajouter. La première vérification part dans la minute qui suit.

Sur le plan gratuit, chaque vérification envoie une requête GET, suit jusqu'à 5 redirections et attend un code 2xx sur la page finale. Si le site ne répond pas en 10 secondes, ou en cas d'erreur réseau, un nouvel essai est fait 2 secondes plus tard avant de déclarer la panne. Un certificat HTTPS expiré ou invalide fait aussi passer le monitor en panne.

3. Règle le seuil de lenteur (facultatif)

Dans le même formulaire, la section Performance permet de fixer un seuil « lent », par exemple 3000 ms, et de cocher M'alerter si le site répond plus lentement que ce seuil. Tu reçois alors un email quand ton site devient lent, et un autre quand il redevient normal. Un site lent reste compté comme disponible : c'est un signal d'alerte, pas une panne.

4. Vérifie tes alertes email

À l'inscription, un canal email vers l'adresse de ton compte est créé automatiquement. Dans Alertes, le bouton Tester t'envoie un email d'essai : vérifie qu'il arrive bien, et pas dans les spams. Tu peux ajouter d'autres adresses (ton prestataire, un associé) : chaque adresse autre que la tienne doit être confirmée par son destinataire avant de recevoir des alertes.

Quand le site tombe, tu reçois un email avec la raison de la panne (par exemple « Code HTTP 503 (attendu 200–299) » ou « Délai d'attente dépassé »). Quand il revient, un second email te le signale.

5. Publie ta page de statut

Dans Page de statut, choisis un identifiant (lettres minuscules, chiffres et tirets), puis clique sur Créer la page. Elle est en ligne à une adresse du type :

https://pinguro.app/status/mon-entreprise

Elle affiche un verdict global, l'état de chaque monitor, une barre de disponibilité sur 90 jours et les incidents récents. Pendant une panne, tu peux y publier des messages depuis la page du monitor concerné. Et dans Maintenance, tu annonces tes interventions prévues : les vérifications faites pendant une maintenance déclarée ne comptent pas dans la disponibilité.

6. Utilise tes deux autres monitors

Le plan gratuit permet 3 monitors actifs. Quelques idées pour les deux restants : la page de connexion de ton espace client, le tunnel de commande, une API, ou une tâche planifiée (sauvegarde, synchronisation) avec un monitor Heartbeat / Cron, qui te prévient quand elle ne tourne plus. Pour ce dernier cas, voir le guide Comment monitorer un cron job.

Ce que le plan gratuit ne fait pas

Pour choisir en connaissance de cause, voici les limites du plan gratuit :

• 3 monitors actifs, vérifiés toutes les 15 minutes au plus court (les heartbeats, eux, peuvent descendre à 1 minute). Une panne peut donc mettre jusqu'à un quart d'heure à être détectée.
• Alertes par email uniquement. Slack, Discord, Telegram et webhook sont prévus avec les plans payants (voir Alerte Slack, Discord ou Telegram sans bruit inutile).
• Pas de vérification de contenu (mot-clé attendu ou interdit), pas d'alerte avant l'expiration du certificat, pas de choix de la méthode HTTP ni des codes acceptés : ces options sont réservées aux plans payants. Pour repérer un site « en ligne » qui affiche une erreur, surveille plutôt une adresse qui renvoie un vrai code d'erreur quand ça va mal, comme un /health.
• Vérifications depuis un seul endroit, un serveur en France.
• Historique des vérifications conservé 90 jours.
• Pas d'API, pas de widgets, pas de groupes de monitors, une page de statut avec la mention « Propulsé par Pinguro ».

Les plans payants ne sont pas encore ouverts : aujourd'hui, seul le plan gratuit est disponible.

Questions fréquentes

Comment savoir si mon site est en panne pour tout le monde ou seulement pour moi ?

Ouvre-le depuis un autre réseau, par exemple ton téléphone en 4G avec le Wi-Fi coupé. S'il s'affiche, le problème vient probablement de ta connexion ou de ton cache. Un service de surveillance externe tranche la question pour toi : il vérifie depuis un autre endroit que chez toi, et garde la trace de ce qu'il a vu.

La surveillance ralentit-elle mon site ?

Non. Une vérification toutes les quelques minutes représente une requête de plus, l'équivalent d'un visiteur qui charge une page. C'est négligeable, même pour un petit hébergement.

Est-ce que ça marche avec WordPress, Shopify, Wix ou un site fait main ?

Oui. La surveillance ne dépend pas de la technologie du site : elle ouvre ton adresse comme le ferait un visiteur. Il n'y a rien à installer sur le site. Seule précaution : si une protection anti-robots bloque les vérifications, autorise l'adresse de l'outil. Pour WordPress en particulier (piège du cache, message « erreur critique », maintenance bloquée), voir le guide Site WordPress en panne.

Est-ce que la surveillance améliore mon référencement ?

Pas directement. Mais un site qui reste en panne longtemps sans que tu le saches n'est accessible ni à tes visiteurs ni aux robots des moteurs de recherche. Réparer vite, c'est limiter les dégâts, et pour réparer vite, il faut savoir vite.

Je gère les sites de mes clients : est-ce que le plan gratuit suffit ?

Pour trois sites, oui. Au-delà, le plan gratuit de Pinguro sera trop juste, et les plans payants ne sont pas encore ouverts. D'autres services proposent plus de monitors en gratuit (voir le tableau plus haut) : choisis selon le nombre de sites, la fréquence dont tu as besoin et l'importance que tu accordes à la page de statut et à l'hébergement en France.

Conclusion

Surveiller son site gratuitement n'a rien de compliqué : un service externe qui vérifie ta page à intervalle régulier, une alerte envoyée à quelqu'un qui la lit, et une petite liste de réflexes pour le jour où elle arrive. Le script maison est un bon moyen de comprendre le principe ; un outil dédié t'évite de devoir le surveiller lui aussi.

Le plus important n'est pas l'outil choisi, c'est de ne plus apprendre une panne par un client. Choisis celui qui correspond à ton nombre de sites, mets-le en place aujourd'hui, et teste une alerte pour vérifier que tout arrive bien.