Production checks
A production check runs a flow on a schedule against the build your customers have, and tells you the moment the journey stops working: by email, Slack, a webhook or PagerDuty.
Add a check
On a project's Production checks page, choose Add a check, then:
- Pick the flow, usually the one that would hurt most if it broke: sign-up, sign-in or checkout.
- Pick the platforms to check it on, and the device for each, with its system: the default (an iPhone 17 or a Pixel 8), or any other on the devices list. A check runs on one device for each platform; to test on more, run the flow on them from its page or from CI.
- Choose how often it runs, and where its alerts go.
Each check gets its own minute within its interval, so a project's checks don't all start at once.
| Plan | Checks run as often as |
|---|---|
| Free | Once a day |
| Starter | Every 15 minutes |
| Team, Business, Enterprise | Every 5 minutes |
Intervals go from 5 minutes to once a day. You can pause a check, and Check now runs it straight away.
Which build it runs on
A check runs on the project's production build for each platform, the one in your customers' hands: on the Builds page, choose Make this the production build. Without one, it uses the newest build. Choose the new build when you release, and checks move to it.
When a check fails
- A failure is checked again at once, on the same flow and build. Nobody is alerted yet, so a blip doesn't wake you.
- If it fails again, an incident opens and alerts go out, with the step that failed, the screen at the time, the recording and, when Trailcam AI can tell, why.
- The next pass resolves the incident, and the same channels hear that it's working again.
A journey that keeps breaking and recovering, three incidents within ten checks, is marked as flapping: its last incident reopens instead of a new one each time, and it needs three passes in a row to resolve.
Runs that couldn't run, and runs that were stopped, don't open or resolve incidents.
When a check gets slower
A journey that still passes but got slow is a problem people feel before any check fails. Trailcam learns each journey's usual time on its device: the middle of its last 20 passing runs there (once it has 5). A run is slower when it takes half as long again and 5 seconds more; its page says so, with the step that slowed most.
After three slower checks in a row, the check is slower: its page says by how much and which step, its chart shades it, and its channels are told. After three checks back within a fifth of the usual time, they hear it's back. If the longer time is expected (the app does more now), Make this the usual time closes it, and only checks from then on count toward the usual time. Each check has a switch for these alerts, on by default.
CI results say when a passing run took markedly longer than on the builds before.
When a check can't run
If a check can't run, for example its flow has errors or the project has no build for a platform, its channels are told after two of its intervals, and again when it's running again.
Alerts
| Channel | Plans | What it sends |
|---|---|---|
| Every plan | To the members you choose | |
| Slack | Starter and up | To a channel, through an incoming webhook |
| Webhook | Starter and up | Signed JSON to your own address |
| PagerDuty | Business and Enterprise | An event through PagerDuty's Events API, opened and resolved with the incident |
A check can send to up to 20 channels. Send test checks a channel works before you rely on it.
Webhooks
Webhooks follow the Standard Webhooks signing scheme, so most libraries can
check them: each request has webhook-id, webhook-timestamp and webhook-signature headers, signed with the
channel's secret (shown once, and rotatable).
| Event | When |
|---|---|
incident.opened | A check failed twice in a row |
incident.flapping | A journey keeps breaking and recovering |
incident.resolved | It passed again |
check.cant_run | A check couldn't run for two intervals |
check.running_again | It's running again |
check.slower | Three checks in a row took markedly longer than usual |
check.back_to_usual | It's back to its usual time |
test | You chose Send test |
Webhooks go only to public https addresses and don't follow redirects. A delivery that fails is tried again after
1, 5, 15, 30, 60 and 120 minutes.
Maintenance windows
Pause a project's checks while you ship or while a service you depend on is down: once (for up to a week), or every week on the days you choose, in your time zone. Checks don't run in a window, so nobody is alerted. A project can have up to 20.
Uptime
Each check shows how much of the last 24 hours, 7, 30 and 90 days it was working, with a bar for each day. Time a check couldn't run never counts as working. Every Monday, everyone in the workspace gets a summary of each check's uptime, incidents and time down, and can turn it off with one click.