Cinq plateformes populaires de monitoring d'API comparées sur ce que les équipes évaluent vraiment : fréquence des checks, flux de requêtes multi-étapes, palier gratuit, intégrations d'alertes, et coût à l'échelle réelle.
| Capacité | LoadFocus | Pingdom | UptimeRobot | Datadog | New Relic |
|---|---|---|---|---|---|
| Fréquence minimum des checks | 30 secondes | 60 secondes | 60 secondes (1 min) | 30 secondes | 30 secondes |
| Flux d'API multi-étapes / chaînés | Oui — login + token + call | Add-on Transaction | Non | Oui (Synthetic API) | Oui (Synthetic Monitor) |
| Palier gratuit avec checks d'API | Oui — 5 checks gratuits | Trial uniquement | 50 monitors / 5 min | Trial uniquement | Gratuit jusqu'à 100 Go ingest |
| Emplacements de check globaux | 26+ régions AWS | 100+ | 13 | 20+ | 20+ |
| Intégrations d'alertes (Slack, PagerDuty, webhook) | Oui — les trois | Oui | Oui | Oui | Oui |
| Tarif pour 50 endpoints @ checks 1 min | À partir de 19 €/mois | À partir de 79 $/mois | À partir de 7 $/mois (limité) | À partir de 5 $/check/mois | Basé sur usage |
L'uptime seul rate la performance dégradée. Ces quatre métriques vous disent si vos APIs sont vraiment en bonne santé — pas juste accessibles.
Temps que prennent les 5% les plus lents des requêtes. Les moyennes cachent la longue traîne ; le p95 l'expose. Un p95 au-dessus de 500 ms sur une API de paiement signifie que de vrais utilisateurs attendent plus que ce qu'ils tolèrent — et ils ne reviennent pas tous.
Combien de temps l'API met à envoyer le premier byte après réception de la requête. Capture les ralentissements DNS, TLS et traitement serveur séparément du transfert réseau. Les pics ici pointent généralement sur l'origine, pas sur le réseau client.
Pourcentage de checks synthétiques qui passent (status code correct + forme de la réponse + dans le budget de latence). En dessous de 99% sur une API de production c'est un incident à alerter, pas une curiosité.
Les checks synthétiques vous disent que l'API est up ; le RUM vous dit si les vrais clients ont vécu la même chose. Couplez les deux — le synthétique vous alerte des pannes, le RUM vous dit l'impact client.
APIs de production qui pilotent du revenu ou bloquent d'autres systèmes : toutes les 30–60 secondes. APIs internes ou peu critiques : toutes les 5 minutes suffisent. En dessous de 30 secondes ça coûte plus cher sans attraper significativement plus de pannes.
Le monitoring d'uptime vérifie juste si l'endpoint répond. Le monitoring d'API valide en plus les status codes, la forme du body de réponse, les budgets de latence et les workflows chaînés (login → token → call). Le monitoring d'API attrape les casses silencieuses que le monitoring d'uptime rate.
Oui — LoadFocus supporte les headers, les tokens OAuth bearer et les requêtes chaînées où la réponse d'une étape (un token) devient l'auth de la suivante. Pas besoin d'exposer un mot de passe de service account en config en clair.
Dans un intervalle de check. Avec des checks de 30 secondes et des alertes Slack/PagerDuty, votre on-call est paginé en moins d'une minute. Configurez les seuils d'alerte pour exiger 2 échecs consécutifs — ça supprime les transitoires d'une seule région.
Oui — GraphQL c'est juste un POST avec un body JSON, entièrement supporté. gRPC nécessite un petit adaptateur (gRPC-Web ou curl sur h2) — la plupart des équipes l'enveloppent dans un proxy REST fin uniquement pour le monitoring.
Le tarif LoadFocus scale avec endpoints × fréquence. 50 endpoints avec checks toutes les minutes coûtent ~19 €/mois. 500 endpoints avec checks toutes les 30 secondes tournent autour de 180 €/mois — environ la moitié de ce que facturent Pingdom ou Datadog pour une couverture équivalente.
