The operations section answers the question “why is it not working” before anything falls over: who executes the builds, what stands in the queue, where the limits run out, what the health checks check, and what moves when the data migrates to another server.
There is no Kubernetes and no rented capacity here: everything lives on your server and in your browsers, and the section shows that honestly.
Runners
Runners are your own Chrome browsers with the installed extension, not a rented pool: your own capacity reserve is the product itself. The table shows the name, the project, the state, the time of the last contact, and the extension version — together with an honest warning when a version has fallen behind the newest among the runners.
The states “online”, “degraded” and “offline” are not stored in the database but derived from how recent the last contact is. That is why they do not stick: the moment a browser stops checking in, the status changes by itself.
A runner can be drained — before a system upgrade, for example. It stops claiming new builds and calmly finishes the current one. The pairing in its browser is preserved, so “Resume” returns it to work at any moment: drain is a lever, not a trap.
The queue
Everything waiting is visible here: AI rounds, test heal campaigns, site crawls, and notification deliveries. Every row carries its state, how long it has waited, and a rough time to finish based on the last completions of the same kind of work.
When the queue is empty, it says so. Something pending can be canceled through the same actions as on your own screens — with a mandatory reason. This screen restarts nothing: it only shows what is waiting. Retries cost nothing and never enter the queue.
Budgets
The limits are shown as a ladder: under 50 %, 50–80 %, 80–100 %, and over the limit. Every project shows how many captures are stored against the cap, how many AI tokens were spent against the task cap, and how many minutes the runs took over the last seven days. When a limit is not set, it says so — “unlimited (self-hosted)”.
It matters to understand what this is for: one runaway AI run can eat a month’s savings. The ladders show where the project stands before that happens. Budgets warn and block new AI starts, but never bill anything — there are no invoices here at all.
Health checks
Six general checks answer for the whole server:
- the agent connection;
- the test runner;
- the database;
- the file storage;
- the public address;
- quotas and budgets.
And four checks per project: the visual configuration, the test files, the default environment, and notification delivery. Each has an understandable reason, dry facts without secrets, a “what to fix” hint, and a button to the place where it gets fixed.
A yellow check can be silenced for a while, with a reason and a term: it comes back by itself and reminds about itself again. A red one cannot be silenced — it has to be restored first. A “proceed without the check” decision, with its reason, lands in the audit log, so it cannot quietly paper over a real breakage.
Degradation
When general checks fall, the product does not pretend everything is fine: a banner with the failed check’s name and a link to where it gets fixed appears on every page. At the same time only the bulk actions that change meaning turn off — “accept all safe”, for example, and the launch of heal campaigns.
Single verdicts, reading, comments, and build runs keep working. That is deliberate: degradation should stand in the way of hasty mass decisions, not stop the work. Decisions made in this mode are marked in the audit log.
Data migration
Migration helps you move to another server or raise a copy for verification. Export and import carry the visual configuration, the environments, the variables, the coverage, the app map, and the baseline signatures with their version data. Baseline images travel only by a separate request and with a 200 MB cap.
Never transferred are credentials — they live only in the server’s vault — plus publication tokens and run history. Tests, actions, and rules are files: they move together with the project folder, because it is under version control.
Import is safe to repeat: the same document a second time answers “everything skipped” — nothing doubles. Before applying there is a trial run that first shows the exact report — what will be created, what updated, and what skipped. The migration itself is also written to the audit log.
Next: how test versions and step pages work — in Test Versions & Steps.