Monitoring d’API17 régions, chaque panne confirmée

Monitoring d’API,
vérifié deux fois.

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.

Choisi par les équipes pour qui la disponibilité passe avant tout.

Lire les témoignages clients

Une requête, vérifiée comme par un client. Méthode, en-têtes, corps, réponse attendue.

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.

  1. 1

    Envoyez la requête de vos clients

    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.

  2. 2

    Décrivez une réponse saine

    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.

  3. 3

    Lancez-le toutes les 30 secondes

    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.

What the probe sendshttp
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"

Six façons dont une API casse. Chacune fait échouer le check.

  • POST /v1/checkout · 503 Service Unavailabledown · confirmed from 3 regions

    L’endpoint qui tombe

    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ée
  • 200 OK · {"error":"upstream timeout"}body check · 422

    200 OK, mauvaise réponse

    Beaucoup 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 contenu
  • GET /v1/orders · 401 Unauthorized401 · expected 200 to 299

    La clé que quelqu’un a changée

    Envoyez 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ête
  • GET /v1/search · no answer after 10 stimeout · down

    Plus lent que la patience de vos clients

    Ré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éponse
  • cert · api.example.com · 7 days leftreminder · Slack and email

    Le certificat de l’hôte de l’API

    Les 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 SSL
  • api.openai.com · 5xx from 3 regionsdependency down

    L’API dont vous dépendez

    Paiement, 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 ?

17 régions, une à la fois. Un échec est revérifié depuis les autres.

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.

  1. Check planifié1 region · every 30 s

    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.

  2. Échec503 · Frankfurt

    Un mauvais code de statut, un texte absent, un timeout ou une connexion refusée. Rien n’est encore envoyé.

  3. RevérificationLondon · N. Virginia · Singapore

    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.

  4. Confirméoutage opens · alerts go out

    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.

  • San FranciscoSFO
  • Californie (N.)CAL
  • Virginie (N.)VIR
  • New YorkNYC
  • TorontoTOR
  • São PauloSAO
  • LondresLDN
  • ParisPAR
  • FrancfortFRA
  • AmsterdamAMS
  • Le CapCPT
  • MumbaiMUM
  • BangaloreBLR
  • SingapourSGP
  • SéoulSEO
  • TokyoTKY
  • SydneySYD

Puis la bonne personne est prévenue. Et vos clients le voient.

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.

  • L’ingénieur d’astreinte, pas un canal

    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 escalade
  • Une page de statut qui se met à jour seule

    Ajoutez 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 statut
  • Silence pendant vos déploiements

    Planifiez 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 bruit

Des alertes vérifiées.Là où travaille votre équipe.

Chaque alerte est revérifiée depuis au moins deux autres régions avant d’arriver dans les outils que votre équipe utilise déjà.

  • Slack
  • Microsoft Teams
  • Google Chat
  • PagerDuty
  • Opsgenie
  • Jira Service Management
  • Discord
  • Telegram
  • Application mobile
  • Email
  • SMS
  • Appel téléphonique
  • Webhooks

Quand une requête ne suffit pas. Des checks d’API enchaînés avec Playwright.

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.

  1. 1

    Se connecter, puis appeler

    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.

  2. 2

    Des assertions sur les champs JSON

    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.

  3. 3

    Comptés comme vérifications navigateur

    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.

orders.spec.tstypescript
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) });
});

Ce que les équipes disent de Hyperping.

Guillermo Rauch
CEO, Vercel
@hyperping est vraiment incroyable
Fabrice Gregoire
Site Reliability Engineer, Alma
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.
Pierre Renaudin
CTO, Slite
Nous avons choisi Hyperping pour offrir à nos utilisateurs un tableau de bord de grande qualité sur nos incidents et l’état de nos services.
Moritz Dausinger
CEO & Founder, Refiner
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.
Gary Gaspar
CEO & Founder, Marker.io
Aujourd’hui, nous ne pourrions plus imaginer faire tourner notre SaaS sans Hyperping.
Jakob Bo Storjohann
CEO, Ideanote
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 de disponibilité

Détectez les pannes dès qu’elles surviennent, depuis plusieurs régions, avant que vos clients ne les remarquent.

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.

Exemple de stack
  • Pingdom100 vérifications de disponibilité + 20 avancées
    149 $US/mois
  • StatuspagePage publique Startup + page privée Growth
    348 $US/mois
  • PagerDutyProfessional · 10 utilisateurs × 25 $US
    250 $US/mois
Coût cumulé

747 $US/mois

8 964 $US sur 12 mois

Tout est connecté, dès la première vérification.

Business
  • 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 mois
60 % de moins

Économisez 5 376 $US par an avec cette combinaison.

Voir les tarifs
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 d’API.

Qu’est-ce que le monitoring d’API ?

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.

Comment surveiller la disponibilité d’une API ?

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.

Hyperping peut-il surveiller des requêtes POST avec des en-têtes et un corps JSON ?

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.

Hyperping peut-il vérifier le contenu d’une réponse d’API ?

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.

À quelle fréquence et depuis où une API peut-elle être vérifiée ?

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.

Comment Hyperping évite-t-il les fausses alertes sur les checks d’API ?

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.

Puis-je surveiller une API qui exige une authentification ?

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.

Hyperping gère-t-il à la fois les checks d’API et les vérifications navigateur ?

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.

Hyperping peut-il surveiller une API interne ?

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.

Le monitoring d’API est-il inclus dans l’offre gratuite ?

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.

Votre premier check d’API, en ligne en une minute.