Surveiller une API, c’est lui envoyer de vraies requêtes à intervalles réguliers et vérifier que les réponses sont correctes, pas seulement que le serveur a répondu. Une API qui renvoie 200 OK avec une liste vide, un message d’erreur dans le corps ou une réponse qui met dix secondes est cassée pour les applications qui en dépendent, même si une vérification simple passerait. Cette checklist détaille ce qu’il faut configurer pour que vos moniteurs d’API détectent les vrais problèmes.
1. Choisir les endpoints
Ne surveillez pas tout. Surveillez ce dont dépendent vos utilisateurs et vos intégrations :
L’endpoint de santé ou de statut, s’il vérifie les dépendances comme la base de données. Un endpoint de santé qui renvoie « ok » sans rien vérifier ne vous apprend pas grand-chose.
L’authentification : l’endpoint qui délivre les jetons ou valide les sessions. S’il tombe, tout tombe.
Les principaux endpoints de lecture : ceux que votre application appelle à chaque écran, comme la liste des commandes ou la récupération d’un profil.
Les parcours d’écriture critiques : paiement, inscription ou récepteurs de webhooks, surveillés avec des données de test. Un moniteur de parcours exécute ce type d’enchaînement d’appels API étape par étape, transmet des valeurs comme un jeton ou un identifiant de commande d’une étape à l’autre et garde les secrets sous scellés.
Les API tierces dont vous dépendez, comme les prestataires de paiement ou de livraison, pour savoir quand le problème ne vient pas de vous. La surveillance des services tiers d’Uptimecheck suit les pages de statut de 31 services comme Klarna, Shopify et Cloudflare, ou toute page hébergée sur Statuspage.
2. Définir la requête : méthode, en-têtes et corps
Une vérification doit ressembler à une vraie requête client :
Méthode : GET pour les lectures, POST, PUT ou PATCH pour les endpoints qui l’exigent.
En-têtes : Accept: application/json, un Content-Type pour les requêtes avec un corps, et tout en-tête personnalisé exigé par votre API, comme un en-tête de version.
Corps : une charge utile courte et valide pour les requêtes POST, par exemple une recherche.
Choisissez des requêtes que l’on peut répéter sans risque chaque minute. Évitez les endpoints qui créent de vraies commandes, envoient des e-mails ou débitent des cartes, sauf si vous utilisez un compte de test dédié.
3. Gérer l’authentification
La plupart des API exigent des identifiants. Les options :
Basic auth pour les endpoints protégés simples.
Clé API ou bearer token dans un en-tête, par exemple Authorization: Bearer <token>.
Créez un compte ou un jeton dédié à la surveillance, en lecture seule. Vous limitez les dégâts en cas de fuite et isolez le trafic de surveillance dans vos journaux. N’oubliez pas que les jetons expirent. Un jeton longue durée en lecture seule évite les fausses alertes quand un jeton de courte durée arrive à expiration.
4. Valider le code de statut
Décidez quels codes de statut signifient un succès. En général 200, 201 ou 204, selon l’endpoint. Méfiez-vous des redirections : une API qui redirige soudain vers une page de connexion renvoie un 3xx, puis un 200 avec du HTML. Pour toute application qui attend du JSON, c’est une panne.
5. Valider le contenu de la réponse
C’est là que la plupart des vérifications d’API pèchent. Vérifiez que la réponse contient quelque chose que seule une API fonctionnelle renverrait :
Un champ qui doit toujours être présent, comme « status »: »ok » ou « id ».
Une valeur connue issue des données de test.
L’absence de texte d’erreur, comme « error ».
Avec Uptimecheck, vous définissez pour chaque moniteur d’API les codes de statut attendus, un mot-clé et des vérifications JSON, par exemple que $.status vaut ok ou qu’un en-tête existe, ainsi que la méthode, les en-têtes (y compris basic auth ou bearer token) et le corps.
6. Fixer des seuils de temps de réponse
Pour une API, lente équivaut désormais à en panne. Les applications mobiles expirent et les intégrations relancent leurs requêtes, ce qui ajoute encore de la charge. Enregistrez le temps de réponse à chaque vérification et fixez un seuil à partir de ce qui est normal :
Analysez une semaine de temps de réponse pour établir la référence.
Placez le seuil d’alerte bien au-dessus des variations normales, par exemple à deux ou trois fois le temps de réponse habituel.
Alertez sur une lenteur durable, pas sur des pics isolés. Une requête lente, c’est du bruit ; une série, c’est un problème.
Dans Uptimecheck, vous fixez une limite de réponse lente par moniteur : vous recevez une alerte de lenteur quand trois vérifications consécutives la dépassent, puis une autre quand le service redevient rapide.
Vérifier depuis plusieurs régions montre si la lenteur est générale ou limitée à un chemin réseau. Uptimecheck vérifie depuis Stockholm, Londres et New York et décompose chaque temps de réponse en DNS, connexion, TLS, serveur et téléchargement : vous voyez quand la lenteur commence et où le temps est perdu.
7. Surveiller toute la chaîne
Une API tombe rarement seule. Ajoutez des moniteurs pour ce dont elle dépend :
Les certificats SSL du nom d’hôte de l’API. Un certificat expiré casse tous les clients d’un coup.
Les enregistrements DNS du domaine de l’API.
Les ressources serveur comme le CPU, la mémoire et le disque des serveurs de l’API.
Les tâches planifiées qui maintiennent les données à jour, avec des heartbeats.
8. Envoyer les alertes aux bonnes personnes
Les alertes d’API reviennent généralement aux développeurs responsables du service. Envoyez-les sur le canal de discussion de l’équipe, et sur un canal qui atteint un téléphone pour les pannes de production la nuit. Utilisez des webhooks pour alimenter vos propres outils de gestion d’incidents. Voir les notifications.
9. Automatiser la création des moniteurs
Si vous déployez souvent de nouveaux services, créez les moniteurs pendant le déploiement. L’API REST d’Uptimecheck (Professional et Business) couvre les moniteurs, les fenêtres de maintenance et les mises à jour de statut, et elle est documentée sur app.uptimecheck.com/docs/api : la surveillance fait ainsi partie de votre pipeline au lieu d’être une étape manuelle après coup. Un serveur MCP permet aux assistants IA de faire de même avec une clé API.
10. Informer les consommateurs de l’API
Si d’autres équipes ou des clients s’appuient sur votre API, proposez-leur une page de statut avec un composant pour l’API. Ils n’auront pas à déboguer leur propre code pendant votre panne.
Les erreurs courantes en surveillance d’API
Ne vérifier que l’endpoint de santé. Il répond souvent correctement alors que les vrais endpoints échouent parce qu’une dépendance est en panne.
Utiliser les identifiants de production d’un vrai utilisateur. Quand il change de mot de passe ou quitte l’entreprise, la surveillance cesse de fonctionner. Utilisez un compte dédié.
Ignorer le corps de la réponse. Une page d’erreur HTML avec un statut 200 passe une vérification qui ne regarde que le statut.
Alerter à chaque réponse lente. Les pics isolés créent du bruit et habituent les équipes à ignorer les alertes.
Oublier les dépendances. L’API va bien, mais le certificat a expiré ou l’enregistrement DNS a changé.
La checklist
Choisissez les endpoints : santé, authentification, lectures principales, écritures critiques, API tierces clés.
Définissez la méthode, les en-têtes et le corps de chaque vérification.
Utilisez un jeton dédié en lecture seule ou des identifiants basic auth.
Définissez les codes de statut attendus.
Validez le contenu : un champ ou une valeur que seule une API fonctionnelle renvoie.
Enregistrez le temps de réponse et alertez sur une lenteur durable.
Vérifiez depuis plusieurs régions.
Surveillez le SSL, le DNS, les serveurs et les tâches planifiées derrière l’API.
Envoyez les alertes à l’équipe responsable, avec un canal qui atteint un téléphone pour la production.
Créez les moniteurs via l’API pendant les déploiements.
En résumé
Un 200 OK est le début d’une vérification d’API, pas sa fin. Envoyez des requêtes réalistes, validez le contenu, surveillez le temps de réponse et couvrez toute la chaîne derrière l’API.
La surveillance d’API avec méthodes, en-têtes et corps personnalisés, vérifications JSON et alertes de réponse lente est incluse dans toutes les offres Uptimecheck. Essayez-la gratuitement pendant 14 jours, sans carte bancaire.