Surveillez la chaîne, pas l'endpoint : API, files, fonctions et crons sur AWS, Azure et GCP sans agent à installer, et des flux qui vous indiquent l'étape exacte où la commande s'est cassée.
3 moniteurs d’URL ou de cron sans frais dans tous les plans. Un pack ajoute les endpoints de santé, les flux et les ressources de votre cloud, surveillées avec la connexion que vous avez déjà.
Flux commande → facture
Dernière exécution : cassée à l'étape 2
Déclencheur · file SQS
orders-in
Envoyé avec son traceId
Étape 1 · ligne dans les logs
/aws/lambda/process-order
Arrivé
1,2 s
Étape 2 · élément DynamoDB
orders
N'est pas arrivé en 2 min
Étape 3 · objet S3
invoices/2026/
Non vérifié
La commande est entrée dans la file et la fonction l'a traitée, mais elle n'est jamais arrivée dans DynamoDB : la panne est entre la fonction et la table.
5
types de moniteurs, de l'URL au flux de bout en bout
3
clouds surveillés sans installer d'agent : AWS, Azure et GCP
2
régions confirment la panne d'une URL avant d'alerter
6
canaux d'alerte, avec heures de silence et relance
En serverless, presque rien ne tombe à l'entrée. Ça tombe derrière : une file qui se bouche, une fonction qui réessaie en silence, un événement que personne ne consomme.
L'endpoint répond, le tableau de bord reste vert et vous l'apprenez par un client. La file grossit depuis des heures, la file d'erreurs est pleine et personne n'a regardé l'âge du plus vieux message.
Nous surveillons l'URL, l'état de chaque composant et les ressources derrière. Un flux de test parcourt la chaîne et vous dit quelle étape n'est pas arrivée, combien de temps chacune a pris et ce qu'a coûté la panne.
Données d’exemple.
Commencez par ce que vous avez et ajoutez de la profondeur quand il le faut. Les moniteurs partagent le quota de l’organisation, quel que soit le cloud ; les flux ont le leur.
Une URL avec des assertions sur le code, la latence, un en-tête, le corps ou un JSONPath. Authentification par bearer, basic, clé d'API ou l'identité de votre compte AWS, Azure ou GCP.
GET /orders · 200 · 142 ms
Lit votre endpoint de santé et sépare chaque composant : une base de données lente rend le service dégradé, pas en panne.
database: pass · cache: warn → dégradé
Fonctions, files, tables, API et workflows sur AWS, Azure et GCP, lus avec votre connexion : erreurs, throttles, âge du plus vieux message et file d'erreurs.
orders-in · plus vieux message de 4 h
Une URL que votre cron ou votre job appelle, chaque minute ou une fois par mois (jusqu’à 35 jours). S’il n’appelle pas à temps, vous êtes alerté.
nightly-billing · dernier signal il y a 3 min
Lance une transaction de test et vérifie qu'elle atteint chaque étape. Il vous indique l'étape exacte qui a cassé et le temps de chacune.
orders-in → logs → orders ✕ → invoices
Un flux envoie un message de test avec un traceId et vérifie qu’il atteint chaque étape dans son délai. Votre code n’a qu’à garder cet id dans la clé de l’élément, l’objet ou la ligne de log, et reconnaître le test pour qu’il ne facture pas, n’envoie pas d’e-mails et ne crée pas de vraies commandes : @aaa-sentinel/health (Node.js) et aaa-sentinel-health (Python) règlent chaque point en une ligne.
Sur AWS et Azure, vous choisissez où entre le test et nous suivons les connexions réelles de votre compte (files, fonctions, règles et abonnements) pour vous proposer les étapes et leurs délais.
Un message dans la file, une invocation, un événement ou une requête, marqué de son traceId et de son traceparent W3C.
Cherche le traceId là où il doit apparaître, avec un délai par étape, et note le temps écoulé depuis la précédente.
Si une étape n'arrive pas, le flux tombe avec cette étape marquée, et l'alerte donne son numéro et son nom : vous savez s'il faut regarder la fonction, la file ou la table.
Sur AWS, il se déclenche avec SQS, Lambda ou EventBridge ; sur Azure, avec Service Bus ou Event Grid ; sur GCP, avec Pub/Sub, Cloud Run ou Eventarc ; et sur n’importe lequel, avec un appel HTTP. Chaque étape se vérifie avec ce que laisse votre chaîne (un élément, un document, un objet ou un blob), une ligne de log ou un appel à notre URL.
Nous lisons tels quels health+json, Spring Boot Actuator, ASP.NET Core Health Checks et les endpoints Kubernetes. Si vous partez de zéro, @aaa-sentinel/health pour Node.js ou aaa-sentinel-health pour Python construit la réponse en trois lignes.
health.ts
import { runHealthChecks } from '@aaa-sentinel/health'
export const handler = () =>
runHealthChecks({ database: () => db.query('select 1') })Un composant en « warn » rend le service dégradé, pas en panne : il apparaît sur la page de statut et part comme événement par webhook, sans réveiller personne.
Un échec isolé ne réveille personne. Chaque moniteur passe par ces états et seul « en panne » ouvre un incident et alerte. Les nouveaux moniteurs observent 24 heures avant d'alerter ; pour les URL et les crons, ils proposent aussi des seuils.
Opérationnel
Les vérifications passent.
Suspect
Un échec sur une URL ou un endpoint de santé. Pas encore d’alerte.
Confirmation
Une URL ou un endpoint de santé est vérifié depuis une seconde région ; une ressource ou un flux, en attendant que l’échec se répète.
En panne
Confirmé : l'incident s'ouvre et l'alerte part sur vos canaux.
Rétablissement
Ça repasse. L'incident se ferme quand ça tient.
Alerte par e-mail, Slack, Microsoft Teams, PagerDuty, Jira Service Management ou webhook, et ouvre un ticket dans Jira ou Linear, avec le même moteur d’alertes que vos alertes de coûts. Le monitoring a sa propre politique : heures de silence, fenêtres de maintenance et une relance si la panne dure.
Ce qui se passe quand quelque chose tombe : ce que ça coûte, comment ça se répare, qui est prévenu et où vous le voyez.
Chaque incident porte sa chronologie, qui s'en occupe, ses notes et ce qu'il a coûté : la valeur d'une minute d'arrêt que vous fixez, dans votre devise, sur la même plateforme que vos dépenses cloud.
En Business, quand la cause a une solution, l’incident vous la propose et elle s’exécute une fois approuvée : renvoyer vers leur file les messages de la file d’erreurs, arrêter la règle ou la Logic App qui échoue, ou augmenter la concurrence réservée qu’une fonction a déjà. L’arrêt et la hausse de concurrence sont annulables.
Regroupez des moniteurs en services qui dépendent les uns des autres. Leur état vient du pire composant ou d’un quorum, les alertes sont envoyées par service et chacun a son propre endpoint health+json dans l’API.
Publiques ou privées avec un lien secret, dans la langue choisie pour chaque page. Les publiques aussi sur votre propre domaine (comme status.votreentreprise.com) avec son certificat, et avec status.json et un flux Atom. En Business, elles portent votre logo et votre nom.
En Business, chaque moniteur peut être attribué à un client : sa page d’état, son propre secret de signature si vous le souhaitez, son rapport de disponibilité du mois en PDF à votre marque, qui peut lui être envoyé par e-mail chaque mois et figure aussi dans le rapport du client, et le décompte de moniteurs pour le refacturer.
Transformez en moniteurs vos alarmes CloudWatch, les health checks Route 53, les alertes de métrique et tests de disponibilité Azure et les uptime checks GCP, sans nouvelles autorisations.
État, durée et disponibilité de chaque moniteur, et les incidents ouverts : pour Prometheus, Grafana Alloy ou l’agent Datadog, ou envoyés en OTLP vers New Relic, Grafana Cloud ou votre collecteur.
Pannes, rétablissements et incidents, signés, dans notre format ou en CloudEvents.
Chaque page de statut publique publie son état lisible par machine et un flux pour les lecteurs et Slack.
Sans autre compte, autre facture ni autre tableau de bord à surveiller : sur la même plateforme que vos dépenses cloud et votre sécurité.
Des URL jusqu'à chaque minute, avec assertions, authentification et confirmation depuis une autre région ; des crons qui alertent s'ils n'appellent pas à temps.
Des flux qui parcourent votre chaîne avec un traceId et indiquent l'étape cassée.
Files, fonctions, tables, API et workflows sur AWS, Azure et GCP, avec la connexion que vous avez déjà.
Chronologie, qui s'en occupe, notes et ce qu'il a coûté, avec des alertes sur six canaux.
Publiques, sur votre propre domaine si vous le souhaitez, ou privées avec un lien secret.
Un PDF par mois, aussi par e-mail ; en Business, un par client à votre marque.
Comment c'est facturé
49 €
par pack et par mois, sur Pro et Business · 39 € dès le 4e
1,96 € par moniteur et par mois ; 1,56 € dès le 4e pack
Commencer| Ce qui est inclus | Sans pack | Avec un pack |
|---|---|---|
| Moniteurs | 3 | 25 par pack |
| Ce qu'ils surveillent | URL et crons | Aussi les endpoints de santé et les ressources de votre cloud |
| Flux de bout en bout | Non inclus | 3 par pack |
| Pages d'état | Non inclus | 1, plus une par client actif en Business |
| Plans | Tous, Free compris | Pro et Business |
| Prix | Gratuit | 49 € par mois ; 39 € dès le 4e |
Les sondes tournent dans notre compte. Dans le vôtre apparaissent la lecture des métriques (sur AWS jusqu’à environ 0,20 USD par ressource et par mois à 10 minutes, le double à 5 ; sur Azure et GCP, cela tient en général dans l’offre gratuite), les requêtes des moniteurs vers votre API et, pour les flux, ce qu’exécute votre chaîne à chaque test et la recherche dans les logs.
3 moniteurs sans frais pour commencer. Des packs à 49 € par mois quand il vous en faut plus.