Des parcours, pas des sondes HTTP
Ouvrir, se connecter, chercher, acheter : vos parcours sont des flows Maestro exécutés sur de vrais appareils, pas des requêtes sur une API. C'est la seule façon de savoir qu'un bouton répond encore.
Sur de vrais téléphones
Le Pingdom des apps mobiles
Un serveur qui répond 200 ne prouve pas que le bouton « Payer » fonctionne. Sentinelle rejoue vos parcours sur de vrais Android, à intervalle régulier, et vous alerte avec le screenshot de l'étape en échec.
Sans carte bancaire pour commencer. Paiement sécurisé par Stripe quand vous changez d'offre.
L'incident s'ouvre à 09:12, l'alerte part à 09:14 avec la capture de l'étape en échec, le rétablissement tombe à 09:31.
Exemple de page de statut. Le passage réel de 24 h sur une app de démo reste à valider.
Un incident, minute par minute
On prévient avant vos clients
Un échec isolé n'est pas une panne : il est revérifié immédiatement sur un autre appareil. L'alerte ne part que si les deux échouent, et elle arrive avec la preuve de l'étape en échec — pas une notification qu'il faut aller expliquer.
-
09:12
Un parcours échoue
« Payer » ne répond plus sur le Redmi 12. La capture de l'étape est prise, le YAML et le logcat sont conservés.
-
09:13
Revérifié sur un autre appareil
Le même parcours repart sur un Galaxy A14. Pas de fausse alerte : un échec isolé ne réveille personne.
-
09:14
L'alerte part, avec la preuve
Le second échec confirme. L'alerte porte le screenshot de l'étape en échec, `steps.json`, `logcat.txt` et `maestro.log`, sous URL signée.
-
09:29
Le passage réussit
Le parcours repasse au vert — vos clients, eux, n'ont rien vu.
-
09:31
Rétabli
L'alerte « rétabli » part au premier passage réussi. L'incident garde ses preuves, même refermé.
Dix-neuf minutes entre la première alerte et le rétablissement, sur un exemple de passage.
Ce que ça fait
Concrètement
Pas de fausse alerte
Un échec isolé est revérifié immédiatement sur un autre appareil. L'alerte ne part que si les deux échouent, et une alerte « rétabli » part au premier passage réussi. Un parcours instable ne réveille personne deux fois.
Les passages en retard sont sautés, pas empilés
Si l'appareil est occupé, le passage est sauté : on ne rattrape pas la nuit en écrasant la file. La règle vient du kit de planification, et les passages sautés sont exclus du calcul de disponibilité.
Disponibilité et durées par étape
24 h, 7 j et 30 j calculées depuis les passages réels, avec la durée de chaque étape. Un parcours réussi mais lent au-delà du seuil produit un `warning` : il se voit sur la page de statut, il ne réveille personne.
La preuve dans l'alerte
Screenshot de l'étape en échec, `steps.json`, `logcat.txt` et `maestro.log`, servis sous URL signée. Chaque incident garde ses preuves, y compris après sa résolution.
Une page de statut pour vos utilisateurs
Optionnelle : un HTML autonome, sans JavaScript ni CDN, protégé par un lien secret de 32 octets et sans aucune URL d'artefact dedans. Elle s'ouvre hors ligne.
Disponibilité et capacité
Des chiffres calculés, pas promis
La disponibilité est calculée depuis les passages réels, sur 24 h, 7 j et 30 j. Un parcours réussi mais lent au-delà de son seuil produit un avertissement : il se voit ici, il ne réveille personne.
99,4 %24 heures
- réussis
- 286
- échecs
- 2
- sautés
- 3
99,8 %7 jours
- réussis
- 2 012
- échecs
- 4
- sautés
- 11
99,9 %30 jours
- réussis
- 8 640
- échecs
- 6
- sautés
- 40
Capacité recalculée
Avec un parcours de 90 s : Pro = 2 appareils, Business = 14.
Un passage sauté — appareil occupé, règle « sauté, pas empilé » — est compté à part et exclu du calcul : c'est une panne de nos appareils, pas de votre app.
La page de statut de vos utilisateurs
Optionnelle : un HTML autonome, sans JavaScript ni CDN, sous un lien secret de 32 octets et sans aucune URL d'artefact dedans. Elle s'ouvre hors ligne.
Tous les parcours fonctionnent
| Connexion | 99,9 % | ok |
| Recherche | 99,8 % | ok |
| Panier → paiement | 98,1 % | warning |
Incident ouvert le 04/10 à 09:12 — référencé, refermé à 09:31. 1 avertissement de durée sur 24 h.
Questions
Questions fréquentes
Recevrai-je la vidéo de l'incident ?
Pas aujourd'hui : côté socle, le job `flow` accepte `record_video` mais n'enregistre rien — seul un job `capture` enregistre l'écran. La preuve livrée est le screenshot par étape, `steps.json`, `logcat.txt` et `maestro.log`. La vidéo dépend d'une capacité du socle encore absente.
Mon app est-elle installée depuis le Play Store ?
Non : `install` n'installe qu'un APK. Une app sans `apk_url` doit déjà être présente sur l'appareil, et `keep_packages` la protège de la remise à zéro.
Puis-je surveiller en 4G ?
Non, l'option n'est pas vendue : aucun appareil n'expose la capacité `sim` au socle. Servir du Wi-Fi en annonçant de la 4G serait un mensonge, et un client s'en apercevrait au premier test.
Combien de parcours puis-je réellement surveiller ?
La capacité est calculée, pas promise. Avec un parcours de 90 s toutes les 5 min, l'offre Pro tient sur 2 appareils et l'offre Business sur 14 — pas plus. La fréquence est la contrainte forte, et `sentinelle capacity` donne le chiffre avant l'inscription.
Un parcours lent déclenche-t-il une alerte ?
Non. Un dépassement de `max_step_ms` produit un `warning`, visible sur la page de statut et dans l'historique. Un `warning` n'est pas un incident.
En toute franchise
Ce que nous ne faisons pas
Un produit qui cache ses limites fait perdre du temps à tout le monde. Voici les nôtres, aujourd'hui.
- La vidéo d'un parcours n'existe pas encore : le job `flow` accepte `record_video` mais n'enregistre rien (seul `capture` le fait). La preuve est le screenshot par étape, `steps.json`, `logcat.txt` et `maestro.log`.
- La 4G n'est pas vendue : aucun appareil n'expose la capacité `sim` au socle.
- L'installation depuis le Play Store n'existe pas : `install` n'installe qu'un APK, et une app sans `apk_url` doit déjà être sur l'appareil.
- La capacité est recalculée, pas promise : avec un parcours de 90 s toutes les 5 min, Pro = 2 appareils et Business = 14. La fréquence est la contrainte forte.
- L'éditeur visuel de parcours n'existe pas : le YAML Maestro se saisit à la main.
- Les SMS sont refusés proprement tant que l'outil d'envoi n'existe pas.
- Le passage réel de 24 h sur une app de démo n'a pas encore été validé : les règles d'alerte, de saut et de disponibilité sont testées, pas éprouvées en continu.
- Le compte de test de l'app est stocké en clair dans la base (loopback/Tailscale) : un chiffrement au repos reste à faire côté socle.
- Stripe n'est pas branché : aucune inscription payante n'est ouverte, et la page de facturation le dit.
- Le sélecteur du socle n'a pas d'exclusion d'appareil : la revérification liste les appareils et épingle un autre serial.
Essayez sur un vrai téléphone
Créez un compte, prenez une clé, lancez votre premier test. C'est gratuit pour commencer.