Journeys, not HTTP probes
Open, sign in, search, buy: your journeys are Maestro flows executed on real devices, not requests against an API. It is the only way to know a button still answers.
On real phones
The Pingdom of mobile apps
A server answering 200 does not prove the "Pay" button still works. Sentinelle replays your journeys on real Android devices, on a schedule, and alerts you with the screenshot of the step that failed.
No credit card to start. Secure payment through Stripe when you change plan.
The incident opens at 09:12, the alert goes out at 09:14 with the screenshot of the failing step, and recovery lands at 09:31.
A sample status page. The real 24-hour run on a demo app is still to be validated.
One incident, minute by minute
We tell you before your customers notice
One isolated failure is not an outage: it is immediately re-checked on another device. The alert only fires when both fail, and it arrives with the evidence of the failing step — not a notification you have to go and explain.
-
09:12
A journey fails
“Pay” no longer answers on the Redmi 12. The failing step is captured; the YAML and the logcat are kept.
-
09:13
Re-checked on another device
The same journey runs again on a Galaxy A14. No false alarm: one isolated failure wakes nobody.
-
09:14
The alert goes out, with evidence
The second failure confirms it. The alert carries the screenshot of the failing step, `steps.json`, `logcat.txt` and `maestro.log`, over signed URLs.
-
09:29
The run succeeds
The journey is green again — your customers saw nothing.
-
09:31
Recovered
The “recovered” alert fires on the first successful run. The incident keeps its evidence, even closed.
Nineteen minutes between the first alert and recovery, on a sample run.
What it does
Concretely
No false alarms
An isolated failure is immediately re-checked on another device. The alert only fires when both fail, and a "recovered" alert fires on the first successful run. A flaky journey never wakes you up twice.
Late runs are skipped, not stacked
If the device is busy the run is skipped: we do not catch up on the night by trampling the queue. The rule comes from the scheduling kit, and skipped runs are excluded from the availability figure.
Availability and per-step durations
24 h, 7 d and 30 d computed from the real runs, with the duration of every step. A journey that succeeds but is slower than its threshold raises a `warning`: it shows on the status page, it does not wake anyone.
The evidence inside the alert
Screenshot of the failing step, `steps.json`, `logcat.txt` and `maestro.log`, served over signed URLs. Every incident keeps its evidence, including after it is resolved.
A status page for your users
Optional: standalone HTML, no JavaScript and no CDN, protected by a 32-byte secret link and carrying no artifact URL. It opens offline.
Availability and capacity
Figures that are computed, not promised
Availability is computed from the real runs, over 24 h, 7 d and 30 d. A journey that succeeds but is slower than its threshold raises a warning: it shows here, it wakes nobody.
99.4%24 hours
- réussis
- 286
- échecs
- 2
- sautés
- 3
99.8%7 days
- réussis
- 2,012
- échecs
- 4
- sautés
- 11
99.9%30 days
- réussis
- 8,640
- échecs
- 6
- sautés
- 40
Capacité recalculée
With a 90-second journey: Pro = 2 devices, Business = 14.
A skipped run — device busy, the “skipped, not stacked” rule — is counted separately and excluded from the figure: that is our hardware failing, not your app.
The status page for your users
Optional: standalone HTML, no JavaScript and no CDN, behind a 32-byte secret link, carrying no artifact URL. It opens offline.
All journeys are working
| Sign-in | 99.9% | ok |
| Search | 99.8% | ok |
| Cart → payment | 98.1% | warning |
Incident opened on 04/10 at 09:12 — tracked, resolved at 09:31. 1 duration warning over 24 h.
Questions
Frequently asked questions
Will I get the video of the incident?
Not today: on the platform side a `flow` job accepts `record_video` but records nothing — only a `capture` job records the screen. The evidence delivered is the per-step screenshot, `steps.json`, `logcat.txt` and `maestro.log`. Video depends on a platform capability that is still missing.
Is my app installed from the Play Store?
No: `install` only installs an APK. An app without an `apk_url` must already be present on the device, and `keep_packages` protects it from the reset.
Can I monitor over 4G?
No, the option is not sold: no device exposes the `sim` capability to the platform. Serving Wi-Fi while advertising 4G would be a lie, and a customer would notice on the first run.
How many journeys can I really monitor?
Capacity is computed, not promised. With a 90-second journey every 5 minutes, the Pro plan holds on 2 devices and the Business plan on 14 — no more. Frequency is the hard constraint, and `sentinelle capacity` gives the number before you sign up.
Does a slow journey trigger an alert?
No. Exceeding `max_step_ms` raises a `warning`, visible on the status page and in the history. A `warning` is not an incident.
In all honesty
What we do not do
A product that hides its limits wastes everybody's time. Here are ours, today.
- The video of a journey does not exist yet: a `flow` job accepts `record_video` but records nothing (only `capture` does). The evidence is the per-step screenshot, `steps.json`, `logcat.txt` and `maestro.log`.
- 4G is not sold: no device exposes the `sim` capability to the platform.
- Installing from the Play Store does not exist: `install` only installs an APK, and an app without an `apk_url` must already be on the device.
- Capacity is recomputed, not promised: with a 90-second journey every 5 minutes, Pro = 2 devices and Business = 14. Frequency is the hard constraint.
- The visual journey editor does not exist: the Maestro YAML is typed by hand.
- SMS are cleanly refused as long as the sending service does not exist.
- A real 24-hour run on a demo app has not been validated yet: the alerting, skipping and availability rules are tested, not proven over time.
- The app test account is stored in clear text in the database (loopback/Tailscale): encryption at rest is still to be done on the platform side.
- Stripe is not wired up: no paid sign-up is open, and the billing page says so.
- The platform selector has no device exclusion: the re-check lists the devices and pins another serial.
Try it on a real phone
Create an account, take a key, run your first test. It is free to start.