← All posts
2026-06-01

Scheduled runs, and getting paged before your users notice

A suite you only run by hand is a suite you'll forget to run the week something breaks. So the second half of Test Chain — after recording and replay — is making a suite run on its own and tell you when it fails.

How the schedule works

Each suite can carry a cron expression and a notify address. A worker checks due schedules, replays the suite in a clean session — its own cookie jar, its own namespaced storage — and records every step's result.

If a step fails, we don't just say "step 4 failed." The run report includes:

That screenshot attaches directly to the alert email. Most of the time it tells you everything you need before you've even opened the dashboard — a button that moved, a modal that's still open, a redirect that landed on an error page instead of the dashboard.

Why isolation matters here

Scheduled runs are unattended by definition, which means they're also the runs most likely to overlap — a nightly suite and an hourly smoke test firing at the same time against the same staging environment. If they shared cookies or localStorage, one run's login would bleed into another's, and you'd get failures that have nothing to do with the thing you actually broke.

Every run gets a session ID, and everything is namespaced under it: __ts_{sessionId}_ for localStorage, __tsc{sessionId}_ for in-page cookies, a dedicated server-side cookie jar for the proxy. Two runs against the same app, at the same second, never see each other.

The result is a suite that runs quietly in the background and only makes noise when something's actually wrong — which is the whole point of automating it.