Oui, la surveillance gratuite est réellement utile
Une croyance tenace veut que la surveillance soit quelque chose qu'on achète une fois que le projet devient « sérieux » — et qu'en attendant, on croise les doigts. C'est prendre l'économie à l'envers. Un projet perso, un produit en démarrage ou un outil interne, c'est précisément là qu'une panne inaperçue fait le plus mal : personne ne fixe un dashboard toute la journée, et le premier signalement utilisateur peut arriver des jours après la casse.
La bonne nouvelle : le cœur de la surveillance d'API — un check HTTP planifié qui vérifie que votre endpoint répond correctement, plus un email quand il s'arrête — coûte si peu à exécuter que des offres gratuites réellement utiles existent. La surveillance gratuite ne vous donnera pas toutes les régions, la fréquence à la minute ou des scénarios de workflows profonds. Mais « je sais en quelques minutes quand mon API est en panne, sans rien payer » est parfaitement atteignable, et c'est une amélioration catégorique par rapport à l'apprendre d'un utilisateur.
La voie DIY : cron jobs et GitHub Actions
Le premier réflexe de tout développeur est de le construire : un cron job avec curl et une alerte en cas d'échec, ou un workflow GitHub Actions planifié qui frappe l'endpoint toutes les quelques minutes. Ça fonctionne, et en construire un apprend beaucoup sur ce qu'implique vraiment la surveillance. Mais la voie DIY a des faiblesses structurelles à connaître avant de s'y fier.
Qui surveille le surveillant ? Un cron job sur le même serveur que votre API meurt avec le serveur — exactement le scénario que vous vouliez attraper. Les workflows planifiés sont best-effort : les plannings GitHub Actions sont régulièrement retardés de plusieurs minutes sous charge et silencieusement sautés sur les dépôts sans activité récente. L'alerte est les 20 % difficiles : envoyer un email à l'échec est facile ; ne pas envoyer 40 emails pour un incident, envoyer un avis de rétablissement et distinguer une micro-coupure d'une vraie panne, c'est là que vit la vraie ingénierie — et là que les scripts maison pourrissent en silence.
Le DIY est un bon exercice d'apprentissage et un palliatif acceptable. Comme filet de sécurité pour quoi que ce soit dont des utilisateurs dépendent, son coût de maintenance dépasse généralement le prix d'un simple service — surtout quand l'offre dont vous avez besoin est gratuite.
Ce qu'une bonne offre gratuite doit inclure
Les offres gratuites varient énormément, et certaines sont des appâts marketing avec expiration à 30 jours ou des plans « gratuits » incapables d'alerter. En évaluer une, c'est vérifier ces essentiels :
De vrais checks HTTP, pas des pings — le moniteur doit évaluer les codes de statut, pas juste la joignabilité. Une fréquence saine — toutes les 5 minutes est une base gratuite solide ; des checks horaires sont décoratifs. L'alerte email incluse — un canal d'alerte verrouillé derrière un paywall annule l'intérêt. La confirmation d'échec — une nouvelle tentative avant d'alerter, pour qu'un paquet perdu ne vous bipe pas. Les avertissements d'expiration SSL — les certificats expirés restent une cause majeure de pannes auto-infligées, et des emails d'avertissement des semaines à l'avance ne coûtent rien au fournisseur. Un minimum de validation de réponse — même une seule assertion de contenu (le corps contient-il ce qu'il devrait ?) attrape la classe d'échec « 200 OK mais cassé » que les checks d'uptime purs ratent.
Le plan gratuit Hobby de ContinuumNexus est construit pour passer cette barre : jusqu'à 5 moniteurs à fréquence de 5 minutes avec alertes email, suivi d'expiration des certificats SSL, une assertion de contenu par moniteur et 30 jours d'historique — sans carte bancaire. Pour un check ponctuel sans même s'inscrire, l'outil gratuit sur continuumnexus.com/free-api-check teste n'importe quel endpoint depuis le navigateur.
Obtenir une vraie couverture avec 5 moniteurs gratuits
Un petit budget de moniteurs impose une discipline saine : surveiller ce qui compte. Une allocation pratique pour un projet typique :
1. Votre endpoint API principal — la route dont l'échec signifie que le produit est en panne. Préférez un endpoint qui touche la base de données à un health check statique, pour qu'une base morte ne se cache pas derrière un statut vert. 2. Votre chemin d'authentification — si la connexion est cassée, tout est cassé pour les vrais utilisateurs, même quand les checks anonymes passent. 3. Votre site public ou landing page — une panne ici coûte des inscriptions et de la confiance. 4. Votre dépendance tierce la plus critique — le prestataire de paiement ou l'API externe sans laquelle votre produit ne fonctionne pas ; savoir qu'eux sont en panne change complètement votre réponse à l'incident. 5. Gardez-en un en réserve — pour ce que vous livrerez le mois prochain.
Deux habitudes multiplient la valeur de n'importe quelle configuration gratuite : pointer chaque moniteur vers un endpoint qui exerce de la vraie logique plutôt qu'un /ping codé en dur, et ajouter une assertion de contenu pour que le check vérifie de vraies données. Un moniteur gratuit qui valide une vraie réponse toutes les 5 minutes bat un moniteur cher pointé vers une page statique.
Quand le gratuit cesse de suffire
La surveillance gratuite a des limites honnêtes, et les reconnaître vaut mieux que les découvrir pendant un incident. Les signaux habituels de dépassement :
Le délai de détection commence à coûter de l'argent. Avec des checks à 5 minutes, la détection au pire cas tourne autour de six minutes. Quand une minute de panne a un prix mesurable, la fréquence à 1 minute cesse d'être un luxe. Vos utilisateurs sont mondiaux. Des checks mono-région ne peuvent pas distinguer « notre API est en panne » de « une région CDN est cassée » — la comparaison multi-région est le diagnostic. Plus de personnes que vous ont besoin des alertes. Un destinataire suffit pour un projet solo ; pas pour une rotation d'astreinte. Les workflows comptent plus que les endpoints. Quand la question passe de « ça répond ? » à « un utilisateur peut-il encore se connecter, créer une commande et payer ? », il vous faut des scénarios multi-étapes qui enchaînent des requêtes authentifiées.
Le bon réflexe est de commencer gratuit et de monter en gamme quand l'un de ces signaux apparaît réellement — pas avant. Une API non surveillée est la seule option véritablement mauvaise, et elle n'a plus d'excuse : l'offre gratuite se configure en cinq minutes environ, soit à peu près le temps de lire un email d'utilisateur mécontent.
