Checks
A check is a recording of a flow that matters, re-driven on a schedule. When it stops working you get the video of the attempt that broke, the step it got to, the requests it saw, and a sentence saying what happened. You write the flow once, by doing it.
Making one
Open a ready recording with a click trail and choose Turn into a check. You give it a name, an origin, a schedule, and a sentence saying what working looks like. We plan the steps from the recording once, show them to you, and replay those steps on every run, so a scheduled run costs no analysis.
A check needs a recording whose interactions were captured: anything from the extension, an upload whose event log came through the API, or a widget report from a site key with interaction capture on. A recording the agent itself produced cannot ground a check, because checking our own output against itself proves nothing.
What “working” means
Write it in your own words: the page says “Order confirmed” and nothing errors. We turn that into conditions a browser can evaluate and show you exactly what we will check, in a sentence you can read back. The conditions available are:
- a piece of text is visible, or is not visible
- an element matching a CSS selector is on the page
- the flow ends on a path matching a pattern
- no request (optionally: no request of one method, to one path pattern) returns an error status
- the console logs no errors
Every condition has to hold for the run to pass. Anything we could not express is listed, not dropped.
What happens when a run does not pass
Not every bad run is a failure, and this is the part worth understanding, because it is what makes a check worth leaving on:
- It retries. A failing attempt is replayed once, because sites and networks are flaky.
- It re-plans. Still failing, we plan the flow again from your recording and run that. If that passes, your app moved rather than broke: the run is recorded as passing, and the new steps wait on the check’s page for you to accept.
- Then it fails. Only now do we record the failing attempt on video, write the explanation, and alert.
- Blocked is not failed. A sign-in wall ends a run as blocked. The agent never types credentials, so it cannot go further, and it does not pretend that means your flow is broken. Unless you attach a signed-in test session, which lets it run behind the sign-in without a password.
- Could not tell is not failed either. If a condition could not be evaluated, the run says so and nobody is woken.
Who hears about it
We tell you when the answer changes: the first failure after a pass, and the recovery. A check that stays broken does not repeat itself more than once a day. Alerts go by email to workspace admins, to a Slack channel if you have connected Slack, and to your webhooks as check.failed and check.recovered. Turn the email off per person in notification settings.
Running one from CI
POST /v1/checks/:id/runs with an API key starts a run and returns its id; GET /v1/check-runs/:id polls it. There is a small command line wrapper (scenerecap check run <id> --wait) and a GitHub Action in the repository. Exit code 0 means passing, 1 means failing, and 2 means we could not tell. A blocked or inconclusive run does not break your build by default, on purpose: a pipeline that goes red because a login wall appeared is one people learn to skip.
Limits, and what this is not
- Checks run in our headless browser pool, from our infrastructure. They tell you whether the flow works from there, not from your customer’s laptop or their network.
- They only run against an origin your workspace has verified. You cannot point one at somebody else’s site.
- Each run counts against a monthly allowance, and a workspace that reaches it has its scheduled runs paused rather than failing.
- A check re-drives the flow you recorded. It does not explore your app, and it will not find a bug in a flow nobody recorded.
- Checks are on Pro and up; hourly is not available yet.