Surveillance d'API

Sachez quand votre API ne répond plus avant vos utilisateurs

AlertSleep envoie la même requête que vos clients — n'importe quelle méthode, vos en-têtes, votre corps de requête, votre jeton — et vérifie le code de statut et la réponse. En cas d'échec, un second emplacement la répète, et vous recevez un SMS ou un appel téléphonique.

Commencer l'essai de 14 jours Voir les tarifs
  • Vérification toutes les 60 secondes
  • Chaque échec confirmé depuis un second emplacement
  • SMS et appels téléphoniques inclus
api.example.com
Opérationnelle
GET /health 200 OK · 84 ms
POST /v1/quotes 200 OK · 142 ms
GET /v1/me 200 OK · 97 ms
108 ms
Réponse moy.
100%
Disponibilité, 30 jours
60 s
Intervalle de vérification

Ce que permet une vérification d'API

Un moniteur correspond à une requête HTTP, configurée comme votre API l'attend.

Toute méthode, tout en-tête, tout corps

GET, POST, PUT, PATCH, DELETE, HEAD ou OPTIONS. Ajoutez vos propres en-têtes, ainsi qu'un corps JSON ou de formulaire aux requêtes POST, PUT et PATCH.

Endpoints authentifiés

Envoyez un jeton Bearer ou une clé API dans un en-tête, ou utilisez Basic Auth. Les en-têtes et les mots de passe sont stockés chiffrés.

Votre définition du succès

Choisissez les codes de statut qui signifient « en ligne ». Tout le reste est un échec, et l'alerte indique le code renvoyé par le serveur.

Vérification du contenu de la réponse

Un moniteur de mot-clé lit aussi le corps de la réponse et échoue lorsqu'un texte de votre choix, comme "status":"ok", est absent. La correspondance respecte la casse.

Confirmation depuis un second emplacement

Une vérification échouée est aussitôt répétée depuis un second emplacement indépendant, avec la même méthode, les mêmes en-têtes, le même corps et les mêmes identifiants. Si elle passe de là-bas, personne n'est réveillé.

Temps de réponse et délais d'attente

Chaque vérification enregistre le temps de réponse, affiché sous forme de graphique et de moyenne. Fixez un délai d'attente entre 5 et 60 secondes pour qu'un endpoint qui ne répond plus soit compté comme hors ligne.

Des moniteurs qui valent la peine

Six vérifications d'API courantes et comment les configurer. Remplacez les adresses d'exemple par les vôtres.

Endpoint de santé

GET https://api.example.com/health

En ligne si : 200

La vérification la plus simple, et celle qui en dit le plus. Faites interroger la base de données et le cache par /health : un 200 signifie alors que l'API peut réellement faire son travail.

POST avec un corps JSON

POST https://api.example.com/v1/quotes
Content-Type: application/json
{"sku": "TEST-1", "qty": 1}

En ligne si : 200 + "price"

Une vraie requête qui traverse votre logique métier. Ajoutez vous-même l'en-tête Content-Type et utilisez un moniteur de mot-clé pour exiger un champ dans la réponse.

Derrière une authentification

GET https://api.example.com/v1/me
Authorization: Bearer <token>

En ligne si : 200

Utilisez un jeton émis uniquement pour la surveillance. Un jeton expiré ou révoqué renvoie 401, que la vérification signale comme un échec — vous savez donc aussi quand les identifiants ne fonctionnent plus.

Requête GraphQL

POST https://api.example.com/graphql
Content-Type: application/json
{"query": "{ health { status } }"}

En ligne si : 200 + "status":"OK"

GraphQL répond souvent 200 même quand la requête échoue, et place le problème dans "errors". Le mot-clé oblige la vérification à exiger les données que vous avez demandées.

Récepteur de webhooks

GET https://shop.example.com/webhooks/payments

En ligne si : 405

Votre endpoint de webhooks de paiement ou de livraison n'accepte que des POST signés. Ajoutez 405 aux codes acceptés : une application qui répond « méthode non autorisée » est en ligne, un délai dépassé ou un 502 ne l'est pas.

Une API dont vous dépendez

GET https://status.example-provider.com/api/v2/status.json

En ligne si : 200 + "indicator":"none"

De nombreux fournisseurs publient un endpoint de statut en JSON. Surveillez-le à côté de votre propre API : une alerte vous dira si la panne vient de chez vous ou de chez eux.

Ce qui se passe quand une vérification échoue

  1. 1

    Nous envoyons votre requête toutes les 60 secondes

    Depuis notre serveur, avec la méthode, les en-têtes, le corps et les identifiants que vous avez définis, puis nous comparons la réponse à vos règles.

  2. 2

    Un second emplacement la répète

    Si elle échoue là aussi, l'incident s'ouvre immédiatement. Si le second emplacement passe, le problème se situe de notre côté du réseau et aucune alerte n'est envoyée.

  3. 3

    Vous êtes alerté, avec la raison

    Par SMS, appel téléphonique, e-mail ou dans la messagerie de votre équipe, avec l'erreur dans le message : le code de statut, le délai dépassé ou le mot-clé manquant.

  4. 4

    Et prévenu quand tout est rétabli

    Un avis de rétablissement part dès la première vérification réussie, et l'incident reste dans l'historique et dans le rapport de disponibilité.

Ce qui compte comme une panne

L'alerte reprend le message enregistré par la vérification. Quelques exemples ci-dessous.

Un code de statut que vous n'acceptez pas

Le serveur a répondu, mais pas avec l'un de vos codes — un 500, un 503 du répartiteur de charge, un 401 après l'expiration d'un jeton.

HTTP 503 Service Unavailable

Le mot-clé est absent

Le statut était correct, mais le corps ne contenait pas le texte exigé par le moniteur.

Keyword '"status":"OK"' not found in response

Pas de réponse à temps

L'endpoint n'a pas répondu dans le délai fixé, le symptôme le plus courant d'une API surchargée.

Connection failed: cURL error 28: Operation timed out after 30001 milliseconds

Aucune connexion

Le DNS ne se résout pas, le port est fermé ou la connexion est refusée.

Connection failed: cURL error 6: Could not resolve host

Un certificat défaillant

Avec la vérification du certificat activée, un certificat expiré, auto-signé ou ne correspondant pas au domaine fait échouer la vérification, tout comme il fait échouer vos clients.

Connection failed: cURL error 60: SSL certificate problem

Les alertes et tout ce qui les entoure

Surveiller une API, c'est la moitié du travail. L'autre moitié consiste à joindre la bonne personne et à garder le silence pendant les travaux planifiés.

Où partent les alertes

E-mail, SMS et appels téléphoniques, ainsi que Slack, Microsoft Teams, Telegram, WhatsApp, Discord et votre propre webhook.
En savoir plus

Fenêtres de maintenance

Planifiez une fenêtre pour un déploiement ou une migration. Les vérifications continuent, mais aucune alerte ne part et la période planifiée ne fait pas baisser votre disponibilité.

Une page de statut pour votre API

Publiez les moniteurs sur une page de statut publique, pour que les développeurs qui utilisent votre API puissent la consulter avant d'ouvrir un ticket.
En savoir plus

Notre propre API REST

Créez des moniteurs, consultez les vérifications et les incidents, et ouvrez une fenêtre de maintenance depuis votre pipeline de déploiement avec un jeton d'API.

Tâches en arrière-plan

Les files d'attente, les imports et les tâches planifiées n'exposent aucune requête que nous pourrions envoyer. Un moniteur cron attend leur ping et vous alerte s'il n'arrive pas.
En savoir plus

Certificat et domaine

Le même moniteur peut surveiller le certificat de l'API et l'enregistrement du domaine, et vous prévenir avant que l'un ou l'autre n'expire.
En savoir plus

Ce que la surveillance d'API ne fait pas

Pour que vous le sachiez avant de vous inscrire, pas après.

  • Un moniteur envoie une seule requête. Il n'y a pas de vérifications multi-étapes qui se connectent, transmettent un jeton à la requête suivante et valident chaque étape.
  • La réponse est vérifiée par son code de statut et, pour un moniteur de mot-clé, par un texte qu'elle doit contenir. Il n'y a pas de validation par schéma JSON ni champ par champ.
  • Le temps de réponse est enregistré, mais ne déclenche pas d'alerte. Un endpoint lent ne lance une alerte qu'une fois le délai d'attente dépassé.
  • Les vérifications partent d'un seul emplacement et chaque échec est confirmé depuis un second. Ce n'est pas un réseau de vérifications réparti dans de nombreux pays.

Besoin de tester un parcours complet ?

Intégrez-le à votre API : un endpoint /health/deep qui exécute le parcours en interne et renvoie 200 ou 500. AlertSleep surveille ensuite ce résultat chaque minute et vous alerte dès qu'il change.

AlertSleep face aux autres pour les API

Le forfait payant le moins cher de chaque service : ce qu'une vérification d'API peut envoyer et quels canaux d'alerte sont inclus.

Fonctionnalité AlertSleep UptimeRobot Better Stack Pingdom
En-têtes et codes de statut personnalisés Oui Oui Oui Oui
Mot-clé dans la réponse Oui Oui Oui Oui
Alertes SMS Inclus Packs de crédits Licence par utilisateur 50 crédits
Alertes par appel téléphonique Oui Packs de crédits Licence par utilisateur Non

Les fonctionnalités des concurrents sont celles de leur forfait payant le moins cher, telles que décrites sur leurs propres sites. Vérifiez-y les informations à jour. (vérifié : octobre 2026)

Comparaisons détaillées : AlertSleep vs UptimeRobot · AlertSleep vs Better Stack · AlertSleep vs Pingdom

Questions fréquemment posées

Qu'est-ce que la surveillance de disponibilité d'API ?
Un service qui envoie une requête à l'endpoint de votre API à intervalle fixe et vérifie la réponse. AlertSleep le fait toutes les 60 secondes et vous alerte lorsque l'endpoint renvoie un code de statut que vous n'acceptez pas, ne répond pas à temps, est injoignable ou omet un mot-clé que vous exigez.

AlertSleep peut-il surveiller des API authentifiées ?
Oui. Ajoutez un en-tête Authorization avec un jeton Bearer, une clé API dans n'importe quel en-tête, ou des identifiants Basic Auth. Ils sont stockés chiffrés et sont également envoyés avec la vérification de confirmation depuis le second emplacement. AlertSleep n'exécute pas de flux OAuth pour obtenir un jeton : utilisez donc un jeton longue durée émis pour la surveillance.

Puis-je surveiller des requêtes POST et GraphQL ?
Oui. Choisissez POST, PUT ou PATCH, collez le corps de la requête et ajoutez un en-tête Content-Type. Pour GraphQL, envoyez la requête en JSON dans un POST et utilisez un moniteur de mot-clé pour exiger le champ demandé, car GraphQL renvoie souvent 200 accompagné d'une erreur.

AlertSleep peut-il valider la réponse JSON ?
En partie. Un moniteur de mot-clé exige un texte dans le corps, comme "status":"ok", et échoue lorsqu'il est absent. Il n'y a pas de validation par schéma JSON ni par chemin ; si vous en avez besoin, vérifiez la réponse dans votre propre endpoint de santé et faites-lui renvoyer un code d'erreur.

En combien de temps AlertSleep détecte-t-il une panne d'API ?
Les vérifications ont lieu toutes les 60 secondes, quel que soit le forfait. Un échec est aussitôt répété depuis un second emplacement et, si les deux concordent, l'alerte part immédiatement : vous êtes généralement prévenu en une ou deux minutes.

Quels codes de statut comptent comme un échec ?
C'est vous qui décidez. Par défaut, 200, 201, 202, 204, 301 et 302 signifient « en ligne » et tout le reste « hors ligne ». Ajoutez ou retirez des codes pour chaque moniteur, par exemple 405 pour un endpoint de webhooks qui n'accepte que les POST.

Un déploiement va-t-il déclencher des alertes ?
Pas si vous planifiez une fenêtre de maintenance pour celui-ci, dans le tableau de bord ou depuis votre pipeline via l'API AlertSleep. Les vérifications continuent, mais aucune alerte n'est envoyée et la fenêtre n'est pas décomptée de votre disponibilité.

Puis-je essayer la surveillance d'API gratuitement ?
Oui, pendant 14 jours. Il n'y a pas de forfait gratuit, mais les deux forfaits commencent par un essai de 14 jours qui inclut la surveillance d'API, sans carte. Après l'essai, comptez à partir de $59 par an. Pour tester un seul endpoint ponctuellement, le test gratuit de temps de réponse ne demande aucun compte.

Envie de vérifier un endpoint dès maintenant ? Lancer le test gratuit de temps de réponse

Commencez la surveillance de votre API dès aujourd'hui

Configurez votre premier endpoint en quelques minutes. Essai gratuit de 14 jours, sans carte.

Commencer l'essai de 14 jours Voir les tarifs