Monitoring de site web gratuit avec alertes en temps réel

Pourquoi surveiller la disponibilité de vos URL ?

Un uptime de 99,9 % autorise 43 minutes d'indisponibilité par mois. Encore faut-il savoir quand elles surviennent. Sans surveillance automatique, une coupure se découvre par un email de client, souvent plusieurs heures après le début de l'incident. Pendant ce temps, le tunnel de conversion est cassé, les formulaires ne partent plus et Googlebot enregistre des 5xx.

Le mécanisme est simple : une requête envoyée à intervalle régulier, une réponse enregistrée, une alerte dès que cette réponse s'écarte de ce qui est attendu.

Quatre raisons de surveiller vos endpoints :

• Détecter avant les utilisateurs : un crash applicatif ou une panne d'hébergeur remonte en quelques minutes, pas au premier ticket de support.
• Protéger le référencement : des 5xx prolongés sur des pages indexées dégradent le crawl et le classement.
• Couvrir les parcours critiques : page de checkout, endpoint REST, formulaire de contact.
• Encadrer les migrations : l'historique de checks montre quand la régression est apparue.

Comment utiliser le monitoring HTTP en 3 étapes

Étape 1 : Ajouter l'URL à surveiller

Saisissez l'URL complète de l'endpoint, protocole compris :

https://captaindns.com/fr/pricing

Commencez par les URL dont l'indisponibilité se paie tout de suite : page d'accueil, checkout, API publique.

Étape 2 : Régler l'intervalle et les conditions d'alerte

Trois réglages suffisent dans la majorité des cas :

• Intervalle de vérification : 5 minutes par défaut. Une expression cron prend le relais pour les besoins particuliers (heures ouvrées uniquement, fenêtre de maintenance exclue).
• Code HTTP attendu : tout code 2xx par défaut. Renseignez un code précis si l'endpoint doit renvoyer exactement celui-là, par exemple 301 pour une redirection ou 401 pour un endpoint protégé.
• Alertes email : un interrupteur par monitor. Les emails partent vers l'adresse de votre compte CaptainDNS, il n'y a pas d'adresse destinataire à saisir par monitor. Sur les plans payants, un webhook HTTPS peut router vers Slack, Discord ou PagerDuty.

Étape 3 : Lancer un check et lire les métriques

Déclenchez un check immédiat pour valider la configuration. Le résultat apparaît en quelques secondes avec le code HTTP, le temps de réponse total et, le cas échéant, le code d'erreur. Le tableau de bord agrège ensuite l'uptime sur 24 h, 7 jours et 30 jours, le temps de réponse moyen et le p95, la heatmap et la liste des incidents.

Comment fonctionne un check HTTP

Chaque check se déroule en quatre étapes, et chacune peut échouer indépendamment des autres.

1. Résolution DNS

Le nom de domaine de l'URL est résolu. Une résolution en échec (NXDOMAIN, SERVFAIL, timeout) marque le check dns_error et déclenche une alerte.

2. Établissement TCP et handshake TLS

Une connexion TCP est ouverte vers l'IP résolue. En HTTPS, le handshake TLS valide la chaîne de certificats, la date d'expiration et la correspondance avec le nom d'hôte. Un certificat expiré ou invalide marque le check tls_invalid.

3. Requête HTTP et lecture de la réponse

La requête part (GET par défaut, ou la méthode configurée). CaptainDNS patiente jusqu'au délai configuré, 10 secondes par défaut et 30 au maximum. Au-delà, le check est marqué timeout. Le code HTTP et le temps de réponse total sont enregistrés.

4. Évaluation et envoi d'alerte

Un check est up si le code HTTP est un 2xx, ou s'il correspond exactement au code attendu lorsque vous en avez renseigné un ; un 5xx, un code hors de l'attendu, un timeout ou une erreur réseau le marquent down. Un passage confirmé de up à down déclenche une alerte ; le retour à up envoie un email de récupération qui clôt l'incident.

Surveiller votre site depuis plusieurs régions

Un monitor mono-région raconte une vérité partielle. Si votre sonde unique se trouve en Europe et qu'un opérateur de transit transatlantique a un problème, le site apparaît up alors que vos clients américains ne l'atteignent plus. Inversement, un incident réseau local près de la sonde fait croire à une panne globale.

CaptainDNS exécute les checks depuis trois zones, sur l'infrastructure Fly.io : Europe (eu) pour l'UE, le Royaume-Uni et l'Afrique du Nord, États-Unis (us) pour l'Amérique du Nord et une partie de l'Amérique latine, Asie-Pacifique (apac) pour le Japon, la Corée, l'Asie du Sud-Est et l'Océanie. Le nombre de régions activables dépend du plan : une seule (Europe) sur les plans d'entrée, jusqu'à trois au-delà. Voir les plans et tarifs.

Trois stratégies de détection de panne

Plusieurs sondes posent une question : à partir de combien de régions en échec faut-il considérer le site comme DOWN ?

• Consensus (défaut) : le monitor passe DOWN si au moins la moitié des régions échouent. Les faux positifs liés à un incident réseau isolé sont filtrés, une vraie panne remonte vite.
• Strict : une seule région DOWN suffit. Adapté aux monitors critiques (paiement, API temps réel) où tout flap régional doit remonter, même bref.
• Unanime : le monitor ne passe DOWN que si toutes les régions échouent. Adapté aux infrastructures distribuées (CDN actif-actif, edge compute) qui tolèrent des flaps régionaux.

Avec une seule région active, les trois stratégies donnent le même résultat : le choix n'apparaît qu'à partir de deux régions.

Analyser la posture de sécurité de votre site

Un monitor uptime répond à une seule question : « le site répond-il ? » Il ne dit rien de la qualité de ce qu'il rend. Un site peut renvoyer 200 en 80 ms pendant des mois avec un certificat proche de l'expiration, un HSTS retiré par un déploiement de reverse-proxy ou une CSP repassée en unsafe-inline. La surveillance de posture comble cet angle mort : elle recalcule périodiquement une note de sécurité sur les URL déjà surveillées et alerte quand elle se dégrade.

Les cinq composants analysés

• Certificat SSL/TLS : validité, chaîne, date d'expiration, versions de TLS acceptées.
• HSTS : présence de l'en-tête, durée max-age, couverture des sous-domaines, préchargement.
• En-têtes de sécurité : CSP, X-Frame-Options, Referrer-Policy et les autres en-têtes de défense en profondeur.
• Poids de la page : volume des ressources chargées, signal d'hygiène de performance.
• Réputation (phishing) : vérification de l'URL surveillée auprès des bases de menaces (Google Web Risk, URLhaus, VirusTotal), mesurée une fois par jour.

Vous sélectionnez les composants à suivre, un au minimum. Décocher un composant l'exclut du calcul sans fausser la note : son poids est redistribué sur les composants restants.

La note sur 100 en deux volets

La note globale est une moyenne pondérée de Sécurité (80 points), qui couvre le certificat, le HSTS, les en-têtes et la réputation, et de Performance (20 points), qui couvre le poids de la page. Chaque composant est classé dans l'une des quatre bandes de l'interface : Excellent, Bon, À améliorer ou Critique. La sécurité pèse quatre fois plus, parce qu'un certificat cassé expose vos visiteurs là où une page lourde ne fait que les ralentir.

Fréquence, référence initiale et alertes

À la première analyse, CaptainDNS enregistre une référence initiale sans envoyer d'alerte. Ensuite, chaque changement notable déclenche un récapitulatif composant par composant, et une alerte préventive part avant l'expiration du certificat, par paliers de 30, 14, 7, 3 et 1 jour. Un onglet dédié affiche la note courante et l'historique sur 180 jours.

La posture s'exécute depuis l'Europe uniquement : le certificat, le HSTS et les en-têtes ne varient pas selon le point d'observation. Elle est disponible à partir du plan Solo, avec un plancher de fréquence et un nombre de monitors par domaine racine variables selon le plan (voir les plans et tarifs).

La note et ses composants peuvent aussi être publiés sur une status page publique : vous choisissez, monitor par monitor, les éléments visibles (note sur 100, certificat, HSTS, en-têtes, poids de la page, réputation). Rien n'est publié par défaut.

Alertes email et webhooks

Une alerte part lorsqu'un check sort des conditions attendues. Voici les cas couverts.

Trois garde-fous contre le bruit

Un site qui flap peut générer des dizaines d'alertes par heure. Trois mécanismes l'en empêchent :

1. Confirmation sur 2 échecs consécutifs : par défaut, aucune alerte ne part avant deux checks en échec d'affilée. Le seuil se règle de 1 à 10 échecs dans la configuration du monitor.
2. Espacement progressif des rappels : une alerte au début du downtime, puis au plus un rappel par heure pendant les 24 premières heures de l'incident, et un rappel par 24 heures au-delà. Une alerte de récupération clôt l'incident au retour.
3. Auto-désactivation : un jour compte comme perdu quand aucun check de la journée n'a réussi. Au 5e jour perdu consécutif, un email d'avertissement part ; au 7e, le monitor est désactivé.

L'email d'alerte contient l'URL concernée, le code HTTP ou le type d'erreur, la latence du dernier check valide, l'horodatage UTC et local, et un lien vers le tableau de bord. Aucun pixel de tracking.

Webhooks HTTP

L'email ne convient pas au routage vers Slack, Discord, PagerDuty ou un système interne de gestion d'incidents. Sur les plans payants, un ou plusieurs endpoints HTTPS reçoivent les événements en POST JSON, signés par un secret partagé pour valider l'origine côté récepteur. Chaque webhook s'abonne aux catégories qui l'intéressent, au nombre de trois : Monitoring, Deployment et DNS. Les alertes de disponibilité relèvent de Monitoring et peuvent partir vers un channel Slack ops, pendant qu'un second webhook ne reçoit que les événements Deployment. En cas d'échec de livraison, CaptainDNS retente avec un backoff exponentiel et enregistre chaque tentative.

Métriques d'uptime, latence p95 et heatmap 30 jours

Le tableau de bord agrège les checks bruts en six métriques.

La latence p95 est un bon indicateur de la performance ressentie. La moyenne masque les pics ; le p95 dit ce que vivent vos utilisateurs dans les 5 % des cas les plus lents.

Heatmap 30 jours

La heatmap visualise les 30 derniers jours sous forme de grille colorée. Chaque case couvre une journée UTC entière, jamais une fenêtre plus fine, et prend sa couleur de l'uptime du jour : vert au-dessus de 99,5 %, orange entre 90 et 99,5 %, rouge en dessous de 90 %, gris en l'absence de données.

Historique et rétention

Chaque check individuel reste consultable 30 jours sur le plan gratuit : horodatage, code HTTP, temps de réponse total, code d'erreur éventuel. Passé ce délai, les checks unitaires sont supprimés automatiquement. La rétention détaillée augmente sur les plans supérieurs, dans la limite de 90 jours appliquée à tous les plans. Les agrégats journaliers (uptime, latence moyenne) ne sont pas purgés ; la profondeur d'historique lisible sur une status page publique dépend du plan, de 30 jours sur le plan gratuit à plusieurs centaines de jours au-delà. Supprimer un monitor efface toutes ses données.

Cas d'usage concrets

Cas 1 : déploiement qui casse la page d'accueil

Symptôme : un déploiement du vendredi soir passe en production. Le lundi matin, un client signale que le formulaire de contact renvoie une erreur depuis le week-end.

Diagnostic : l'historique des checks montre un basculement en down avec des codes 500 à 21 h 12 le vendredi, puis 61 heures de downtime continu. L'alerte email de bascule était bien partie, vers une adresse qui n'était plus relevée.

Action : router les alertes de la catégorie Monitoring vers un webhook Slack en plus de l'email, et ajouter un monitor dédié sur l'endpoint du formulaire plutôt que sur la seule page d'accueil.

Cas 2 : fausse alerte sur un incident réseau régional

Symptôme : une alerte DOWN arrive à 3 h du matin. Le site répond normalement depuis votre poste.

Diagnostic : le monitor tourne sur trois régions en stratégie Strict. Le détail par région montre timeout depuis la sonde apac uniquement, pendant 12 minutes, avec eu et us en 200. Ce n'est pas une panne du site mais un incident de transit local.

Action : basculer ce monitor sur Consensus, qui exige au moins la moitié des régions en échec. Réserver Strict aux endpoints où un flap régional est déjà un incident client, comme une API de paiement.

Cas 3 : certificat expiré un dimanche

Symptôme : le site répond 200 depuis des semaines, l'uptime est à 100 %, et pourtant les navigateurs affichent depuis ce matin un avertissement de sécurité.

Diagnostic : le renouvellement automatique du certificat a échoué en silence après un changement de configuration du reverse-proxy. Le monitor uptime n'a rien signalé avant l'expiration : il constate un certificat invalide une fois la date passée, jamais dans les semaines qui la précèdent.

Action : activer la surveillance de posture sur ce monitor. L'alerte d'expiration part par paliers de 30, 14, 7, 3 et 1 jour, et la note chute dès que le certificat ou le HSTS régresse.

Comparatif des outils de monitoring de site web

CaptainDNS n'est pas un outil de monitoring spécialisé : c'est un tableau de bord DNS, SPF, DKIM, DMARC et blacklists auquel s'ajoutent le monitoring HTTP et la posture de sécurité, avec un plan de données opéré en Union européenne. Le choix se joue donc sur le périmètre. Si vous surveillez uniquement de l'uptime et qu'il vous faut des dizaines de monitors gratuits, un acteur spécialisé comme UptimeRobot répond mieux au besoin. Si vous cherchez des status pages très personnalisables, BetterStack est plus abouti sur ce terrain. CaptainDNS a du sens quand la surveillance HTTP prolonge une surveillance DNS et email déjà en place, et quand la localisation européenne du traitement compte. Quotas et prix exacts sur la page des plans et tarifs.

Quotas, limites et plans disponibles

Le plan gratuit inclut 1 monitor HTTP vérifié toutes les 5 minutes depuis l'Europe, soit 288 checks par jour, avec alertes email illimitées, 30 jours d'historique détaillé, heatmap, latence p95 et 1 status page publique, sans carte bancaire. Les plans payants augmentent le nombre de monitors, le nombre de régions activables, la durée de rétention et le nombre de webhooks simultanés, et débloquent la surveillance de posture à partir de Solo. La grille complète est maintenue à jour sur la page des plans et tarifs, qui fait référence en cas d'écart avec cette page.

Surveiller votre site depuis l'Europe : RGPD et souveraineté

Le monitoring HTTP est un traitement de données : vous transmettez des URL, parfois des en-têtes d'authentification. CaptainDNS opère son plan de données depuis l'Union européenne, avec une sonde Europe en France et en Allemagne, une base PostgreSQL et des sauvegardes en France, et une équipe technique européenne. Les sondes États-Unis et Asie-Pacifique sont optionnelles et n'exécutent que les checks : les résultats sont rapatriés vers la base européenne, qui reste le stockage primaire quel que soit le plan. Le tableau de bord n'utilise aucun cookie de tracking ni script analytics tiers. Vous êtes responsable de traitement pour vos monitors et CaptainDNS agit en sous-traitant au sens de l'article 28 du RGPD ; le DPA est disponible sur demande.

Limites du monitoring HTTP

Le monitoring HTTP de CaptainDNS ne couvre pas les besoins suivants :

• Monitoring TCP brut sur des ports non-HTTP (SMTP, FTP, base de données).
• Transactions multi-étapes : parcours utilisateur sur plusieurs pages avec assertions successives.
• Sondes hors des trois zones Europe, États-Unis et Asie-Pacifique : ni Amérique du Sud, ni Afrique, ni Moyen-Orient.
• Endpoints non publics : une URL derrière un VPN ou un pare-feu privé reste injoignable depuis nos sondes.

Les alertes Slack, Discord, PagerDuty et Opsgenie ne passent pas par des intégrations natives : elles s'obtiennent via les webhooks HTTPS, en laissant la destination gérer le formatage final.

FAQ - Questions fréquentes

Q : Qu'est-ce que le monitoring de site web ?

R : Le monitoring de site web consiste à vérifier en continu la disponibilité et la latence d'une URL HTTP. L'outil envoie une requête à intervalle régulier, enregistre la réponse et déclenche une alerte en cas d'échec. La panne est ainsi détectée avant vos utilisateurs.

Q : À quelle fréquence CaptainDNS vérifie-t-il mon URL ?

R : Par défaut, un check HTTP toutes les 5 minutes sur chacun de vos monitors, soit 288 vérifications par jour. Une expression cron permet de personnaliser la cadence : check à la minute en heures ouvrées, fenêtre de maintenance exclue.

Q : Comment recevoir une alerte quand mon site tombe ?

R : Activez les alertes email à la création du monitor : elles partent vers l'adresse de votre compte CaptainDNS, sans destinataire à saisir. Dès qu'un échec est confirmé (5xx, timeout, erreur DNS, certificat TLS invalide), une alerte part. Les rappels sont ensuite espacés d'au moins une heure, et un email de récupération clôt l'incident au retour du site.

Q : Que signifie un uptime de 99,9 % ?

R : Un uptime de 99,9 % autorise environ 8 heures et 45 minutes d'indisponibilité par an, soit 43 minutes par mois. C'est le seuil couramment retenu en production. À 99,99 %, le budget tombe à 52 minutes par an.

Q : CaptainDNS est-il gratuit pour surveiller mon site ?

R : Le plan gratuit inclut 1 monitor HTTP vérifié toutes les 5 minutes, des alertes email illimitées, la heatmap 30 jours et la latence p95, sans carte bancaire. Les quotas des autres plans sont détaillés sur la page des tarifs.

Q : Puis-je monitorer une URL authentifiée ou un endpoint privé ?

R : Oui pour les URL publiques. Les en-têtes HTTP personnalisés (Authorization, X-API-Key) permettent d'interroger un endpoint protégé par token. Une URL derrière un VPN ou un pare-feu privé reste injoignable depuis nos sondes.

Q : Comment partager mes résultats de monitoring ?

R : Liez votre monitor à une status page publique CaptainDNS. Elle expose l'uptime, la latence et l'historique des incidents à vos clients, sans leur ouvrir votre tableau de bord privé.

Q : Qu'est-ce que la note de posture de sécurité ?

R : C'est une évaluation sur 100 recalculée périodiquement sur cinq composants : certificat SSL/TLS, HSTS, en-têtes de sécurité, poids de la page et réputation (phishing). Elle se répartit en Sécurité (80 points) et Performance (20 points), et alerte à chaque régression ou avant l'expiration du certificat. Disponible à partir du plan Solo.

Q : Quels composants la posture analyse-t-elle et à quelle fréquence ?

R : Certificat SSL/TLS, HSTS, en-têtes de sécurité HTTP, poids de la page et réputation (phishing). Vous choisissez les composants suivis (au moins un) et la fréquence, d'une fois par heure à une fois par jour selon le plan. Le poids de la page et la réputation restent mesurés une fois par jour au maximum.

Outils complémentaires

Ressources utiles

• Google SRE Book : Service Level Objectives (définition de référence des SLA, SLO et budgets d'erreur derrière les 99,9 %)
• RFC 6797 (spécification de HTTP Strict Transport Security, l'un des composants de la note de posture)
• MDN : Content-Security-Policy (documentation de l'en-tête CSP et de ses directives)
• Documentation Let's Encrypt (renouvellement automatique et durée de vie des certificats TLS)
• CA/Browser Forum (organisme qui fixe les exigences de base des certificats publics, dont leur durée de validité maximale)
• Fly.io : régions (liste des régions de l'infrastructure sur laquelle tournent les sondes)