Monitoring de disponibilité
Détectez les pannes dès qu’elles surviennent, depuis plusieurs régions, avant que vos clients ne les remarquent.
Monitoring de disponibilité d’API avec votre méthode, vos en-têtes et votre corps, toutes les 30 secondes depuis 17 régions. Un échec est revérifié depuis d’autres régions avant que quiconque soit alerté.
20 moniteurs gratuits toutes les 5 min, sans carte bancaire.
Un check d’API est un moniteur HTTP : Hyperping envoie la requête que vous décrivez selon un planning et compare la réponse avec celle d’un endpoint en bonne santé. Configurez-le dans le dashboard, l’API ou Terraform.
GET, POST, PUT, PATCH, DELETE, HEAD ou OPTIONS, avec des en-têtes personnalisés comme un jeton Authorization ou une clé d’API, et un corps JSON, form ou brut. Le Content-Type suit le corps.
N’importe quel 2xx, tout jusqu’à 3xx, ou un code de statut précis. Ajoutez un texte que le corps doit contenir, comme "status":"ok", et un timeout : une réponse plus lente compte comme une panne.
Les checks tournent entre les régions choisies, une région par check. Toutes les 30 secondes sur les offres payantes, toutes les 5 minutes en Free, et le bouton Test l’exécute une fois avant d’enregistrer.
POST /v1/checkout/health HTTP/1.1
Host: api.example.com
Authorization: Bearer $API_TOKEN
Content-Type: application/json
{"dry_run": true, "currency": "usd"}
# Up when: status 200 to 299
# and the body contains "status":"ok"Un déploiement, un pool de connexions saturé, un worker planté. Toute réponse hors des codes de statut attendus fait échouer le check, et les autres régions le confirment avant que quiconque soit alerté.
Comment une panne est confirméeBeaucoup d’API répondent 200 avec une erreur dedans. Mettez dans Body contains le texte qu’une réponse saine contient toujours, activez Count it as down, et un texte absent fait échouer le check.
Vérifier le contenuEnvoyez le même en-tête Authorization ou la même clé d’API que vos clients. Si la clé est révoquée ou si le service d’authentification casse, le 401 fait échouer le check comme une panne.
Réglages de la requêteRéglez le timeout de vos clients, de 5 à 60 secondes. Une réponse plus lente compte comme une panne, et le temps de réponse de chaque check est conservé par région.
Temps de réponseLes navigateurs pardonnent beaucoup de choses que les clients d’API ne pardonnent pas. Chaque moniteur HTTPS vérifie son certificat tous les jours : expiration, chaîne, nom d’hôte et révocation, avec des rappels avant qu’il n’expire.
Monitoring SSLPaiement, e-mail, fournisseur de modèles : quand leur service tombe, le vôtre aussi. Surveillez leurs endpoints comme les vôtres, ou voyez quels services populaires sont en panne en ce moment.
Est-ce en panne ?Un check en échec ne compte jamais seul. D’autres régions choisies relancent aussitôt la même requête, et seul un échec qu’elles constatent aussi ouvre une panne et alerte votre équipe.
Chaque check part de l’une de vos régions, le suivant de la suivante : quelques régions couvrent le monde sans multiplier les requêtes.
Un mauvais code de statut, un texte absent, un timeout ou une connexion refusée. Rien n’est encore envoyé.
D’autres régions choisies relancent aussitôt la même requête, sans attendre l’intervalle suivant. Si l’une d’elles reçoit une bonne réponse, aucune panne n’est ouverte.
Seul un échec que les autres régions constatent aussi ouvre une panne, alerte les canaux du moniteur et lance sa politique d’escalade.
Choisissez les régions les plus proches de vos utilisateurs et de votre API, trois ou plus, pour qu’un échec puisse être confirmé ailleurs.
Un échec confirmé lance la politique d’escalade du moniteur et passe le service en rouge sur votre page de statut. Quand l’API répond de nouveau, la panne se ferme et la page redevient opérationnelle.
Liez une politique d’escalade au moniteur : Slack d’abord, puis SMS et appel téléphonique à la personne d’astreinte, puis la suivante si personne n’accuse réception.
Astreinte et escaladeAjoutez le moniteur à une page de statut comme service. Quand la panne est confirmée, son statut change sur la page, puis revient quand l’API repart.
Pages de statutPlanifiez une fenêtre de maintenance pour une migration ou une mise en production, et les moniteurs de l’API n’alertent pas pendant ce temps. Ajoutez un délai d’alerte pour les endpoints qui se rétablissent seuls.
Réduire le bruitChaque alerte est revérifiée depuis au moins deux autres régions avant d’arriver dans les outils que votre équipe utilise déjà.
Les moniteurs HTTP vérifient une requête face à un code de statut et un corps. Pour une connexion avant l’appel, ou des assertions sur des champs JSON, écrivez un vérification navigateur qui ne fait que des requêtes d’API.
Obtenez un jeton, passez-le à la requête suivante et vérifiez ce qui revient : les flux qu’une requête seule ne couvre pas, écrits avec le fixture request de Playwright, sans ouvrir de navigateur.
Vérifiez la valeur d’un champ, un type, la longueur d’un tableau, un en-tête. Les secrets restent dans les variables d’environnement du check, et une exécution en échec garde ses logs et sa trace.
Ils tournent au plus toutes les 5 minutes et comptent dans vos vérifications navigateur : 3 en Essentials, 10 en Pro, 25 en Business. Gardez-les pour les quelques flux qui comptent, à côté de vos parcours utilisateur Playwright.
import { test, expect } from '@playwright/test';
test('log in, then read the latest order', async ({ request }) => {
const login = await request.post('https://api.example.com/v1/auth/token', {
data: {
client_id: process.env.CLIENT_ID,
client_secret: process.env.CLIENT_SECRET,
},
});
expect(login.status()).toBe(200);
const { access_token } = await login.json();
const res = await request.get('https://api.example.com/v1/orders?limit=1', {
headers: { Authorization: `Bearer ${access_token}` },
});
expect(res.status()).toBe(200);
const body = await res.json();
expect(body.data).toHaveLength(1);
expect(body.data[0]).toMatchObject({ status: expect.any(String) });
});
@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 d’API vérifie depuis l’extérieur de votre infrastructure que vos endpoints répondent, répondent correctement et à temps. Hyperping envoie la requête que vous définissez, avec sa méthode, ses en-têtes et son corps, depuis 17 régions selon un planning, vérifie le code de statut et le corps de la réponse, et alerte votre équipe une fois l’échec confirmé. Voir la définition dans notre glossaire.
Créez un moniteur HTTP avec l’URL de l’endpoint, choisissez la méthode, ajoutez les en-têtes et le corps qu’envoient vos clients, puis le code de statut attendu et le texte que le corps doit contenir. Choisissez les régions et l’intervalle, puis les canaux d’alerte ou la politique d’escalade. Hyperping lance le check dès lors et conserve chaque temps de réponse. Voir créer un moniteur.
Oui. Les moniteurs HTTP envoient des requêtes GET, POST, PUT, PATCH, DELETE, HEAD ou OPTIONS avec des en-têtes personnalisés et un corps JSON, form ou brut, depuis le dashboard ou l’API. L’en-tête Content-Type suit le type de corps.
Oui, avec Body contains : un texte exact, sensible à la casse, que la réponse doit contenir, comme "status":"ok". Activez Count it as down dans le dashboard et un texte absent fait échouer le check ; via l’API, required_keyword le fait d’office. Les moniteurs HTTP n’évaluent pas de chemins JSON : pour des assertions sur des champs JSON, écrivez un vérification navigateur avec le fixture request de Playwright.
Toutes les 30 secondes sur les offres payantes et toutes les 5 minutes sur l’offre Free, depuis 17 régions en Amérique du Nord, Amérique du Sud, Europe, Asie, Australie et Afrique. Chaque check part à tour de rôle de l’une des régions choisies. Voir les régions.
Un check en échec ne compte jamais seul. D’autres régions choisies relancent aussitôt la requête, et seul un échec qu’elles constatent aussi ouvre une panne et alerte quelqu’un. Un délai d’alerte et le code de statut attendu suppriment le reste du bruit. Voir faux positifs.
Oui, quand un en-tête suffit : un jeton bearer Authorization, une authentification Basic ou un en-tête de clé d’API, envoyé à chaque check. Quand un jeton doit d’abord être obtenu, un check Playwright se connecte, passe le jeton à l’appel suivant et garde les identifiants dans des variables d’environnement. Les flux OAuth et les certificats clients (mTLS) ne sont pas intégrés aux moniteurs HTTP.
Oui. Les moniteurs HTTP couvrent les requêtes d’API uniques, et les vérifications navigateur Playwright les parcours utilisateur et les appels d’API enchaînés, à côté du monitoring ping, port, DNS, cron et SSL dans le même compte, avec l’astreinte et les pages de statut. Les équipes qui le comparent à Checkly peuvent lire Hyperping comme alternative à Checkly.
Pas depuis l’intérieur de votre réseau : les checks partent de l’internet public, l’endpoint doit donc y être accessible. Pour une tâche ou un service qui ne tourne qu’en interne, un moniteur de tâches cron fonctionne dans l’autre sens : il contacte Hyperping, et c’est le silence qui déclenche l’alerte.
Oui. L’offre Free comprend 20 moniteurs avec des vérifications toutes les 5 minutes, les vérifications par mot-clé et une page de statut, sans carte bancaire. Essentials ajoute les vérifications toutes les 30 secondes, l’astreinte avec alertes par appel et 3 vérifications navigateur. Voir les tarifs.