Monitoring de disponibilité
Détectez les pannes dès qu’elles surviennent, depuis plusieurs régions, avant que vos clients ne les remarquent.
Monitoring DNS pour les enregistrements A, MX, TXT et sept autres types, vérifiés toutes les 30 secondes par rapport à la réponse attendue.
Les moniteurs DNS sont inclus à partir du plan Essentials.
Le monitoring DNS interroge vos enregistrements à intervalle régulier et traite un enregistrement manquant, une mauvaise réponse ou un serveur de noms muet comme une panne. Il attrape ce qu’un check HTTP rate : les serveurs vont bien, mais personne ne les trouve.
Un nettoyage de zone, un changement de fournisseur DNS, une modification d’infrastructure qui a perdu une ligne. Les serveurs restent en ligne et le nom ne se résout plus. Le check suivant échoue.
Doc du monitoring DNSUn compte de registrar piraté ou une modification bien intentionnée envoie le nom ailleurs. Indiquez la réponse attendue, et toute autre valeur compte comme une panne.
Réponses attenduesLes enregistrements MX et les entrées SPF ou DKIM vivent dans le DNS : un check du site web ne les voit jamais. Surveillez les enregistrements MX et TXT à part, avec l’entrée qui doit y figurer.
Types d’enregistrementsAprès une migration, un serveur de noms peut continuer à servir l’ancienne zone. Interrogez chacun directement avec la même réponse attendue : celui qui est en retard échoue seul.
Serveurs de noms personnalisésQuand votre hébergeur DNS a un incident, tous les services derrière lui s’éteignent d’un coup. Des checks depuis jusqu’à 18 régions montrent si c’est une région ou partout.
Régions de monitoringUn enregistrement expiré emporte son DNS avec lui, et le moniteur DNS échoue dès que ça arrive. Les alertes d’expiration de domaine vous préviennent jusqu’à 90 jours avant.
Alertes d’expiration de domaineChaque moniteur DNS vérifie un type d’enregistrement sur un nom d’hôte. La valeur à droite est celle à laquelle une réponse attendue est comparée.
192.0.2.1L’adresse IPv4 vers laquelle pointe un nom d’hôte. Le type par défaut, et celui qui met un site hors ligne.
2001:db8::1L’adresse IPv6. Elle mérite son propre moniteur quand les visiteurs en IPv6 passent par un autre chemin.
example.cdn.netUn alias vers un autre nom d’hôte, comme un CDN, un load balancer ou un service hébergé.
mail.example.comLes serveurs de messagerie. Comparé sur l’hôte de messagerie, quelle que soit sa priorité.
ns1.example.netLes serveurs de noms faisant autorité. Repère une délégation déplacée là où vous ne l’avez pas mise.
include:_spf.example.netEntrées SPF, DKIM, DMARC et de vérification de domaine. Une entrée peut être vérifiée parmi d’autres.
ns1.example.netLe début d’autorité de la zone. Comparé sur son serveur de noms principal.
sip.example.comEmplacements de services pour SIP, XMPP et d’autres. Comparé sur l’hôte cible.
letsencrypt.orgLes autorités de certification autorisées à émettre des certificats pour le domaine.
mail.example.comLe DNS inverse, le nom derrière une adresse IP. Les serveurs de messagerie sont jugés dessus.
Pour surveiller plusieurs types d’enregistrements sur le même domaine, créez un moniteur par type : A pour le site web, MX pour les e-mails, TXT pour SPF. Chacun a sa réponse attendue, ses régions et ses alertes.
Un enregistrement qui pointe vers la mauvaise adresse répond quand même. La réponse attendue transforme une requête DNS en vérification de votre propre configuration.
Le check passe tant qu’un enregistrement la contient, sans tenir compte de la casse. Laissez-la vide et n’importe quelle réponse compte. Les enregistrements MX et SRV sont comparés sur leur hôte, CAA sur sa valeur.
Par défaut, chaque région interroge via son propre résolveur, comme le ferait un visiteur. Indiquez un serveur de noms, par IP ou nom d’hôte, pour vérifier directement vos serveurs faisant autorité ou un résolveur public après un changement.
Chaque check garde les enregistrements renvoyés, le temps de résolution et l’erreur, comme NXDOMAIN ou SERVFAIL : vous distinguez un enregistrement supprimé d’un serveur de noms lent.
La réponse attendue est 192.0.2.1. L’enregistrement la contient toujours, le check passe donc. Supprimez l’enregistrement ou faites-le pointer ailleurs, et le check suivant échoue.
Les moniteurs DNS partagent les alertes de tous les autres moniteurs : les mêmes canaux, délais d’alerte, politiques d’escalade et plannings d’astreinte, et la même status page que lisent vos utilisateurs.
L’enregistrement répond et contient la valeur attendue si vous en avez défini une. Chaque check enregistre la réponse et la durée de la résolution.
Aucun enregistrement, une erreur du serveur de noms, ou aucun enregistrement ne contenant la réponse attendue. L’incident s’intitule : example.com failing A DNS resolution.
Le serveur de noms ne répond pas dans le délai du moniteur. L’incident indique que example.com is timing out on DNS resolution.
La bonne réponse est revenue dans toutes les régions. L’incident se résout et un avis de rétablissement part sur les mêmes canaux.
Un check DNS en échec part sur les canaux de votre choix et remonte votre politique d’escalade jusqu’à ce que quelqu’un en accuse réception.
Mettez protocol à dns, puis dns_record_type, et au besoin dns_expected_answer et dns_nameserver. Les mêmes champs modifient un moniteur existant.
Le serveur MCP accepte les mêmes champs : Claude, Cursor ou un autre agent peut ajouter un moniteur DNS pour chaque domaine que vous lancez.
Quand les deux échouent ensemble, le problème vient du nom. Quand seul le HTTP échoue, c’est le serveur. Deux moniteurs sur le même domaine vous disent où regarder d’abord.
curl -X POST https://api.hyperping.io/v1/monitors \
-H "Authorization: Bearer $API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "Mail DNS",
"url": "example.com",
"protocol": "dns",
"dns_record_type": "MX",
"dns_expected_answer": "mail.example.com",
"dns_nameserver": "ns1.example.net"
}'Un moniteur DNS échoue une fois l’enregistrement expiré. Les alertes d’expiration de domaine lisent la date de fin auprès du registre et vous préviennent jusqu’à 90 jours avant, et le monitoring SSL vérifie le certificat servi par chaque moniteur HTTPS.

@hyperping est vraiment incroyable

Chez nous, Hyperping a la réputation d’être plus réactif que Datadog. Nous recevons généralement les notifications de Hyperping avant celles de Datadog.

Nous avons choisi Hyperping pour offrir à nos utilisateurs un tableau de bord de grande qualité sur nos incidents et l’état de nos services.

Les alertes en temps réel de Hyperping nous signalent quand l’application est en panne. Elles arrivent parfois avant même qu’AWS ne s’en rende compte ou ne nous prévienne.

Aujourd’hui, nous ne pourrions plus imaginer faire tourner notre SaaS sans Hyperping.

Hyperping excelle sur tous les plans : une mise en place fluide, la tranquillité d’esprit et un service client attentif.
C’est un ticket client qui vous apprend que votre site est en panne.
Détectez les pannes dès qu’elles surviennent, depuis plusieurs régions, avant que vos clients ne les remarquent.
Un agent léger suit le CPU, la mémoire et le disque pour repérer les problèmes avant qu’ils ne provoquent une panne.
Des tests Playwright qui repèrent les connexions et paiements en échec avant vos clients.
Soyez alerté quand une sauvegarde ou une tâche planifiée échoue en silence, pas des jours plus tard.
Les alertes joignent la bonne personne sur Slack,
Teams, par SMS ou par appel téléphonique, selon ce qui la réveille.
Gardez vos certificats sous contrôle. Soyez alerté avant leur expiration, pour que vos clients se connectent toujours en toute sécurité.
Planifiez les rotations, répartissez la charge et voyez qui est d’astreinte. Chaque incident parvient à la bonne personne, au bon moment.
USD · Facturation mensuelle pour toutes les offres
Trois abonnements pour tout faire tourner.
747 $US/mois
8 964 $US sur 12 moisTout est connecté, dès la première vérification.
299 $US/mois
3 588 $US sur 12 moisÉconomisez 5 376 $US par an avec cette combinaison.
Vérifié le . Tous les montants sont en USD ; les prix en devise locale peuvent différer.
Il s’agit d’un exemple de stack à trois outils, et non de la configuration la moins chère possible ni d’une comparaison fonctionnalité par fonctionnalité. Pingdom et PagerDuty incluent aussi des fonctionnalités de page de statut ; toutes les équipes n’auront pas forcément besoin d’un abonnement Statuspage séparé. Les frais d’utilisation et les connecteurs payants ne sont pas inclus. Les totaux annuels correspondent à 12 paiements mensuels, et non à des devis d’abonnement annuel.
Le monitoring DNS interroge vos enregistrements DNS à intervalle régulier et vous alerte quand un enregistrement ne se résout plus, se résout vers la mauvaise valeur ou ne répond plus à temps. Une requête ponctuelle vous dit ce qu’un résolveur renvoie maintenant ; un moniteur la répète depuis plusieurs régions et alerte quelqu’un quand la réponse change. Voir le monitoring DNS dans la doc.
Parce que le DNS tombe en panne alors que tout le reste semble en bonne santé. Vos serveurs restent en ligne et les checks HTTP peuvent continuer à passer depuis un résolveur qui a gardé l’ancienne réponse en cache, alors que les visiteurs d’un autre résolveur ne vous joignent plus, et les e-mails peuvent être rejetés pendant que le site fonctionne. Un moniteur DNS vérifie les enregistrements eux-mêmes : ces pannes vous alertent comme n’importe quelle panne.
Créez un moniteur DNS pour l’enregistrement et indiquez la réponse attendue, par exemple l’IP d’un enregistrement A ou l’hôte de messagerie d’un enregistrement MX. Hyperping fait échouer le check quand aucun enregistrement ne contient cette valeur : un enregistrement modifié, supprimé ou détourné déclenche une alerte. Il vérifie un type d’enregistrement par moniteur et ne garde pas l’historique de chaque changement dans la zone.
A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, CAA et PTR. Chaque moniteur vérifie un type d’enregistrement sur un nom d’hôte : pour surveiller A, MX et TXT sur le même domaine, il faut trois moniteurs, chacun avec sa réponse attendue et ses alertes.
Oui. Donnez au moniteur un serveur de noms, par adresse IP ou nom d’hôte, et chaque check l’interroge directement. Visez vos serveurs de noms faisant autorité pour voir un changement dès sa publication, ou un résolveur public pour confirmer qu’il s’est propagé. Sans serveur indiqué, les checks utilisent le résolveur de chaque région de monitoring.
Jusqu’à toutes les 30 secondes, depuis jusqu’à 18 régions de votre choix, comme tout autre moniteur. Chaque check enregistre le temps de résolution et les enregistrements renvoyés : vous voyez ce que chaque région a reçu.
Il en repère le symptôme : un enregistrement A, NS ou MX qui ne contient plus la valeur que vous avez définie. Avec une réponse attendue sur chaque enregistrement critique, un enregistrement détourné fait échouer le check suivant et alerte votre astreinte. Hyperping ne valide pas DNSSEC et ne surveille pas les domaines sosies, et contrer la compromission d’un registrar est un autre travail.
Oui. Les alertes d’expiration de domaine lisent la date de fin de l’enregistrement auprès du registre et vous préviennent 7 à 90 jours avant, une fois par domaine. Elles accompagnent les moniteurs HTTP, ping, port et DNS, et sont détaillées sur la page monitoring SSL et expiration de domaine.
Non. Les moniteurs DNS sont inclus dans les plans Essentials, Pro et Business, et comptent dans les moniteurs du plan. Le plan Free couvre les moniteurs HTTP, mot-clé, ping et port. Voir les tarifs.
Oui. Dans l’API des moniteurs, mettez protocol à dns, puis dns_record_type, et au besoin dns_expected_answer et dns_nameserver. Le serveur MCP accepte les mêmes champs : un agent IA peut ajouter un moniteur DNS pour vous.