Monitoring de disponibilité
Détectez les pannes dès qu’elles surviennent, depuis plusieurs régions, avant que vos clients ne les remarquent.
Monitoring synthétiqueWeb Vitals à chaque run Vos parcours clés,
Vos parcours clés,
en vrai Playwright.
Monitoring synthétique des parcours qui rapportent : vos scripts Playwright se connectent et paient dans un vrai navigateur toutes les 5 minutes. Une étape en échec est revérifiée avant toute alerte.
Essai gratuit de 14 jours, vérification navigateur incluse. Sans carte bancaire.
Choisi par les équipes pour qui la disponibilité passe avant tout.
Lire les témoignages clients
Qu’est-ce que le monitoring synthétique ? Un utilisateur de test qui ne dort jamais.
Le monitoring synthétique exécute des visites scriptées de votre site ou de votre API selon un planning, depuis l’extérieur de votre infrastructure, et vous alerte quand une étape échoue. Il repère une connexion ou un paiement cassé avant le premier client, même quand personne ne visite le site.
Check d’uptime : interroge le serveur
Envoie une requête toutes les 30 secondes et lit le code de statut, le temps de réponse et un mot-clé. Rapide et peu coûteux, mais un bouton de connexion cassé répond toujours 200.
Monitoring de disponibilitéCheck synthétique : utilise le site
Ouvre la page dans un vrai navigateur, exécute son JavaScript, clique, tape et vérifie ce qui s’affiche, comme le ferait un utilisateur. Il repère les connexions et paiements cassés et les pages qui restent blanches.
Vérifications navigateurReal user monitoring : attend les visiteurs
Mesure ce que vivent les vrais visiteurs : il ne voit donc un problème qu’après que quelqu’un l’a subi, et ne voit rien à 3 h du matin sans trafic. Les checks synthétiques tournent selon un planning, qu’il y ait des visiteurs ou non.
Monitoring synthétique de transactions. Pour les parcours qui rapportent.
Une vérification navigateur parcourt tout un parcours utilisateur, étape par étape, et échoue sur l’étape qui casse. Voici ceux que les équipes vérifient en premier.
- step 'Sign in' · expect(page).toHaveURL(/dashboard/) failedoutage confirmed from San Francisco
Connexion et SSO
Un changement de fournisseur d’identité, un client secret expiré, une boucle de redirection. Le check se connecte avec un compte de test et échoue quand le tableau de bord n’apparaît jamais.
Surveiller une connexion Auth0 - step 'Pay with test card' · timeout 30000mson-call paged · video and trace attached
Panier et paiement
Ajouter au panier, remplir l’adresse, payer avec une carte de test dans l’iframe de paiement, puis attendre la confirmation. Le parcours qui fait perdre de l’argent en premier est celui à vérifier en premier.
Tester un paiement Stripe - step 'Create account' · getByText(/check your inbox/) not visiblealert sent · screenshot attached
Inscription et onboarding
Créez un compte avec un nouvel e-mail à chaque run et vérifiez l’écran d’accueil : un formulaire cassé ou un e-mail qui n’arrive plus ne freine pas votre croissance en silence.
Tester les liens e-mail et l’OTP - page.goto('/pricing') · 200 OK · h1 not visiblecheck failed · console error in the trace
Les pages rendues dans le navigateur
Les single-page apps et les frameworks hydratés répondent 200 avec une coquille vide. Seul un navigateur qui exécute le JavaScript voit l’erreur qui laisse la page blanche.
Repérer les erreurs d’hydratation - step 'Search' · product-card count 0check failed at step 'Search'
Recherche et fonctions clés
Taper une requête, attendre les résultats, vérifier qu’il y en a. De même pour un tableau de bord qui charge des données, un envoi de fichier ou un téléchargement dont vos utilisateurs dépendent.
12 scripts prêts à l’emploi - POST /v1/auth/token · 200 · GET /v1/orders · 500check failed on the second call
Parcours d’API en plusieurs étapes
Récupérer un token, le passer à l’appel suivant et vérifier le JSON, sans ouvrir de page. Pour un seul endpoint, un monitor HTTP est plus simple.
Monitoring d’API
Des tests Playwright standard. Aucun enregistreur à apprendre, aucun format dont sortir.
Chaque check est un test Playwright standard en TypeScript, exécuté sur Node 24 avec Playwright 1.59.1 et les packages courants inclus. Gardez les fichiers dans votre dépôt et lancez-les en local avec les mêmes versions.
- 1
Écrivez un test Playwright standard
Collez un fichier .spec.ts, partez de l’un des 12 modèles ou enregistrez-en un avec le codegen de Playwright. Aucun format propriétaire : le même fichier tourne sur votre machine.
- 2
Gardez les secrets hors du script
Identifiants de test et tokens d’API vont dans les variables d’environnement du check et se lisent avec process.env. Découpez les étapes avec test.step() et chacune est rapportée séparément.
- 3
Lancez-le une fois, puis planifiez-le
Run teste le script depuis l’éditeur et affiche chaque étape et les logs. Enregistrez : il tourne toutes les 5 minutes depuis Francfort et San Francisco et alerte comme n’importe quel monitor.
login.spec.tstypescript
import { test, expect } from '@playwright/test';
test('user can log in', async ({ page }) => {
await test.step('Open the login page', async () => {
await page.goto('https://app.example.com/login');
});
await test.step('Sign in', async () => {
await page.getByLabel('Email').fill(process.env.EMAIL);
await page.getByLabel('Password').fill(process.env.PASSWORD);
await page.getByRole('button', { name: 'Sign in' }).click();
});
await test.step('Dashboard loads', async () => {
await expect(page).toHaveURL(/\/dashboard/);
await expect(page.getByTestId('user-menu')).toBeVisible();
});
});Une étape en échec est revérifiée. Puis vous voyez exactement ce qui a cassé.
Les parcours navigateur sont capricieux : un script tiers lent, un aléa réseau. Un run en échec est relancé aussitôt depuis l’autre région, et seul un second échec ouvre une panne, avec tout ce qu’il faut pour la déboguer.
- Run planifiéevery 5 min · Frankfurt, then San Francisco
Chaque run exécute tout le script dans un navigateur neuf, depuis Francfort et San Francisco à tour de rôle. Chaque étape, ligne de log et Web Vital est conservée.
- Étape en échec'Pay with test card' · Frankfurt
Une assertion qui ne tient pas, un locator qui n’apparaît jamais, ou un run qui dépasse son délai. Rien n’est encore envoyé.
- Double vérificationsame script · San Francisco
Le run est relancé aussitôt depuis l’autre région. Un réseau capricieux ou un incident ponctuel y passe, et aucune panne n’est ouverte.
- Confirméoutage opens · alerts go out
Seul un échec qui se reproduit ouvre une panne, alerte les canaux du monitor et lance sa politique d’escalade.
Étapes
✗ Pay with test card · 30.0sChaque test.step() apparaît dans le run avec un statut vert ou rouge et sa durée : l’alerte désigne l’étape qui a cassé.
Capture et vidéo
failure.png · video.webmJointes à chaque run en échec. Voyez ce que le navigateur a vu : le bandeau cookies en travers, le toast d’erreur, le spinner qui ne s’arrête jamais.
Trace Playwright
trace.zipJointe à chaque run en échec. Rejouez-le action par action, avec le DOM, la console et les requêtes réseau à chaque étape.
Logs
TimeoutError: 30000msToute la sortie du run et l’erreur, conservées pour chaque run, en échec ou non.
Les Core Web Vitals à chaque run. Sans une ligne de code en plus.
Chaque page ouverte par votre script est mesurée pendant son chargement. Le check trace les cinq métriques dans le temps et les affiche à chaque run : une mise en production lente apparaît à côté de l’étape qu’elle a ralentie.
- LCP≤ 2,500 ms
Largest Contentful Paint
Le temps avant que le plus grand élément visible s’affiche.
- CLS≤ 0.1
Cumulative Layout Shift
À quel point la mise en page bouge pendant le chargement.
- TBT≤ 200 ms
Total Blocking Time
Le temps pendant lequel le thread principal était trop occupé pour répondre.
- FCP≤ 1,800 ms
First Contentful Paint
Le temps que vos utilisateurs passent devant un écran blanc.
- TTFB≤ 800 ms
Time to First Byte
La vitesse de réponse du serveur, depuis chaque région.
Les seuils sont les limites « bonnes » de Google. L’INP exige une vraie interaction utilisateur : les checks synthétiques ne le collectent pas.
Puis la bonne personne est prévenue. Et vos clients le voient.
Les vérifications navigateur sont des monitors comme les autres : mêmes alertes, politiques d’escalade et pages de statut que vos checks d’uptime, d’API et SSL, dans un seul compte.
L’ingénieur d’astreinte, pas un canal
Associez une politique d’escalade au check : Slack d’abord, puis SMS et appel à la personne d’astreinte, puis la suivante si personne n’acquitte.
Astreinte et escaladeUne page de statut qui se met à jour seule
Ajoutez le check à une page de statut comme service, par exemple Checkout. Quand la panne est confirmée, vos clients la voient, et la page repasse à opérationnel au rétablissement.
Pages de statutDes alertes là où est déjà votre équipe
Slack, Microsoft Teams, e-mail, SMS, appels, PagerDuty ou Opsgenie : les vérifications navigateur utilisent les mêmes canaux, regroupements et mises en sourdine que vos monitors d’uptime.
Alertes
Des alertes vérifiées.Là où travaille votre équipe.
Chaque échec de vérification navigateur est relancé depuis une seconde région avant d’atteindre les outils que votre équipe utilise déjà.
Slack
Microsoft Teams
Google Chat
PagerDuty
Opsgenie
Jira Service Management
Discord
Telegram
Application mobile- SMS
- Appel téléphonique
- Webhooks
Ce que les équipes disent de Hyperping.
@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.
Monitoring, pages de statut et astreinte.Une seule plateforme. Soyez averti avant vos clients.
Monitoring des serveurs
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.
Vérifications navigateur / E2E
Des tests Playwright qui repèrent les connexions et paiements en échec avant vos clients.
Monitoring des tâches cron
Soyez alerté quand une sauvegarde ou une tâche planifiée échoue en silence, pas des jours plus tard.
api.acme.com is down. HTTP 503 from Paris, confirmed from Frankfurt and N. Virginia.9:42 AM
Incident published on status.acme.com. 1,240 subscribers notified by email.9:43 AM
api.acme.com is back up. Downtime 4 min 12 s, incident resolved automatically.9:46 AM
View incident
Canaux de notification
Les alertes joignent la bonne personne sur 
Slack, Teams, par SMS ou par appel téléphonique, selon ce qui la réveille.
Monitoring SSL
Gardez vos certificats sous contrôle. Soyez alerté avant leur expiration, pour que vos clients se connectent toujours en toute sécurité.
Calendrier d’astreinte
Planifiez les rotations, répartissez la charge et voyez qui est d’astreinte. Chaque incident parvient à la bonne personne, au bon moment.
Trois outils. Une facture allégée.Monitoring, pages de statut et astreinte. Au même endroit.
USD · Facturation mensuelle pour toutes les offres
La combinaison d’outils
Trois abonnements pour tout faire tourner.
- Pingdom100 vérifications de disponibilité + 20 avancées149 $US/mois
- StatuspagePage publique Startup + page privée Growth348 $US/mois
- PagerDutyProfessional · 10 utilisateurs × 25 $US250 $US/mois
Coût cumulé
747 $US/mois
8 964 $US sur 12 moisTout est connecté, dès la première vérification.
- 1 000 moniteurs
- 10 pages de statut
- 20 membres d’équipe
- Astreinte et escalades
- Vérifications toutes les 20 secondes
- Support prioritaire
Une plateforme. Un abonnement.
299 $US/mois
3 588 $US sur 12 mois60 % de moins
Voir les tarifs Économisez 5 376 $US par an avec cette combinaison.
Sources et hypothèses tarifaires
Vérifié le . Tous les montants sont en USD ; les prix en devise locale peuvent différer.
- Pingdom Synthetic Monitoring : 149 $US/mois pour 100 vérifications de disponibilité, 20 vérifications avancées et 350 crédits SMS. Tarif en USD issu de notre analyse du 17 août 2026 ; le calculateur en ligne affichait des prix en EUR lors de cette vérification, le tarif en USD n’a donc pas été revérifié de façon indépendante aujourd’hui.
- Statuspage : une page publique Startup (99 $US/mois, 1 000 abonnés, 10 membres d’équipe) et une page privée Growth (249 $US/mois, 300 abonnés authentifiés, 15 membres d’équipe).
- PagerDuty Professional : 25 $US/utilisateur/mois en facturation mensuelle, pour 10 utilisateurs. Son tarif de 21 $US nécessite une facturation annuelle.
- Hyperping Business : 299 $US/mois en facturation mensuelle. Le tarif affiché de 249 $US/mois est l’équivalent mensuel arrondi de l’abonnement annuel à 2 990 $US/an et n’est pas utilisé dans cette comparaison.
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.
Questions sur le monitoring synthétique.
Qu’est-ce que le monitoring synthétique ?
Le monitoring synthétique exécute des checks scriptés sur votre site ou votre API selon un planning, depuis l’extérieur de votre infrastructure, pour vérifier que les parcours clés fonctionnent toujours. Il n’attend pas le trafic réel : un utilisateur robot se connecte, cherche ou paie toutes les quelques minutes et vous alerte quand une étape échoue. Voir la définition dans notre glossaire.
Quelle différence entre monitoring synthétique et monitoring d’uptime ?
Un check d’uptime lit la réponse HTTP : code de statut, temps de réponse et, en option, un mot-clé. Une vérification navigateur synthétique rend la page et la parcourt en cliquant. Connexions cassées, paiements bloqués et erreurs JavaScript renvoient souvent encore 200 : seule une vérification navigateur les voit échouer. La plupart des équipes utilisent les deux : le monitoring d’uptime pour chaque endpoint, les vérifications navigateur pour les quelques parcours qui comptent le plus.
Quelle différence entre monitoring synthétique et real user monitoring ?
Le real user monitoring (RUM) mesure ce que vivent les vrais visiteurs : il a besoin de trafic et signale les problèmes une fois que des utilisateurs les ont rencontrés. Le monitoring synthétique rejoue le même parcours scripté selon un planning : il détecte un parcours cassé la nuit ou avant un lancement, sans aucun visiteur. Hyperping fait du monitoring synthétique, pas du RUM.
Qu’est-ce que le monitoring synthétique de transactions ?
Le monitoring synthétique de transactions vérifie de bout en bout des parcours en plusieurs étapes comme la connexion, l’inscription ou le paiement, plutôt qu’une seule page. Dans Hyperping, chaque transaction est un script Playwright, et chaque test.step() est rapporté avec son propre statut et sa durée : l’alerte dit quelle étape a cassé. Voir le modèle de paiement.
Comment fonctionnent les vérifications navigateur de Hyperping ?
Une vérification navigateur exécute votre script Playwright dans Chromium headless selon un planning. Le runtime par défaut utilise Node 24 et Playwright 1.59.1, avec les packages courants inclus. Un check échoue quand une assertion casse ou que le run dépasse son délai, et les secrets comme les identifiants de test sont stockés chiffrés et passés en variables d’environnement. Voir vérifications navigateur.
Que se passe-t-il quand une vérification navigateur échoue ?
Hyperping relance le run aussitôt depuis l’autre région, ce qui écarte les aléas réseau et les échecs ponctuels. Si la relance échoue aussi, une panne s’ouvre, et vos alertes et votre politique d’escalade démarrent. Chaque run garde ses étapes et ses logs, et les runs en échec joignent aussi une capture, une vidéo et une trace Playwright à rejouer action par action.
Hyperping mesure-t-il les Core Web Vitals ?
Oui. Sur le runtime actuel, chaque navigation de votre script enregistre LCP, CLS, TBT, FCP et TTFB sans code supplémentaire. Le check les trace dans le temps et affiche les valeurs de chaque run. L’INP exige une vraie interaction utilisateur : les checks synthétiques ne le collectent pas.
Puis-je exécuter les mêmes scripts Playwright en local ?
Oui. Les vérifications navigateur sont des tests Playwright standard, sans enregistreur ni format propriétaire. Installez la même version de Playwright et les mêmes packages que le runtime, et le script se comporte de la même façon sur votre machine, en CI et dans Hyperping. Voir installation locale de Playwright.
À quelle fréquence tournent les vérifications navigateur, et combien puis-je en avoir ?
Toutes les 5 minutes au plus, ou une fois par jour au moins, depuis Francfort et San Francisco à tour de rôle. Essentials inclut 3 vérifications navigateur, Pro 10 et Business 25, en plus de vos monitors d’uptime, pages de statut et astreintes ; l’essai de 14 jours en inclut une. Le plan Free a des monitors d’uptime mais pas de vérifications navigateur. Voir les tarifs.
Quels outils de monitoring synthétique comparer ?
Cela dépend de vos besoins : vérifications navigateur scriptées, checks d’API, emplacements privés ou aussi real user monitoring, et du prix que vous acceptez de payer par run. Nous avons comparé 36 outils dans les meilleurs outils de monitoring synthétique, et les équipes qui viennent de Checkly peuvent lire Hyperping comme alternative à Checkly.