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 those who execute the runs. There are two kinds: the built-in one — a headless browser in the container on the server — and Chrome with the addon on your computer. There is no rented capacity pool: your own reserve is the product itself. The table shows the name, the project, the state, the time of the last contact and the version, plus an honest warning when a version has fallen behind the newest among runners of the same kind. The built-in one carries a “built-in” badge next to its name: versions of different kinds are never compared with each other, because their browsers differ.
An empty list at idle is normal, not a breakage: the built-in runner does not keep itself in memory while there is no work, and shows up again when a run lands in the queue. There is a separate “Built-in runner” row in Settings → UI testing: whether it is available and when it last checked in. It is not to be confused with the “Addon connected” line — that one refers to Chrome only.
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.
Any runner — built-in or Chrome — can be drained: before a system upgrade, for example. It stops claiming new runs and calmly finishes the current one. The settings in its browser are 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.
The runner check behaves differently. Normally it judges by the time of the last contact: recent is good, long ago is a reason to look into it. But when the built-in runner works on demand, there is no contact at idle: the check honestly counts it available, not running, and an empty runners list is green for it, not a breakage. The check turns red in a different case — when the runner’s launch failed; the error itself is visible in the details then.
Checks are performed only while someone is looking at them: the diagnostics screen is open — the product queries the database, the storage and the addresses; it is closed — the querying stops. The first reader to come back gets a fresh picture. That is by design: a server nobody watches should not keep checking itself on its own.
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.
Memory at idle
The system-health data has a separate section about memory: how much is taken by the product itself (the current and peak working set), how the garbage collector behaves, and how many records sit in temporary stores. These are readings only — the snapshot starts and cleans nothing, and it is safe to look at.
Why it is needed: a server running for days tends to accumulate memory. The snapshot answers whether there is anything to accumulate: a steady working set and empty temporary stores mean nothing is leaking. At the same time no CPU is spent at idle either — the product’s internal loops wake on events, not on a timer.
And the main point: at idle the product returns the memory it took. If nobody did anything for 15 minutes — no runs went through, no chat work and no screens open — the taken memory is handed back to the system and temporary stores are cleared. How many minutes count as idle is set by the TEST_APP_IDLE_TRIM_MINUTES variable: the value 0 disables the return entirely. That is how the product lives comfortably on a small machine next to other programs.
You do not have to wait fifteen minutes to see how it works: the administrator has a separate action — a forced memory release. It starts the same cleanup without waiting for idle, and immediately answers how much memory was returned to the system.
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.