Sessions & Artifacts
What a run captures — video, logs and commands — where to find it, and how long we keep it.
Every run becomes a session you can open and watch, so a failed CI job is something you can look at rather than a red exit code.
Open one at Automate → Sessions and click any row.
Where to find a run
| What it drove | Where it lands |
|---|---|
| A desktop browser, or a browser on a phone | Sessions |
| An app on a phone | Mobile Sessions |
| An Espresso or XCUITest build | Mobile Apps → Runs — one run per build, one session per device |
An Appium run that drove Safari or Chrome on a phone tested a browser, so it lands in the first list. That is usually why a mobile session isn't where you expected it.
What a run captures
| Works on | |
|---|---|
| Video | Every browser |
| Browser console | Chrome, Edge, Firefox 118+ |
| Network requests | Chrome, Edge, Firefox 123+ |
| Driver logs | Every browser |
| Commands — everything your code asked the browser to do, in order | Every session |
Video is off unless you ask for it. Set recording: true. The three log captures are on by default on Selenium and off by default on Playwright — see Selenium or Playwright.
Safari captures no console or network at all: it has no protocol we can read them from.
Video: one file, or one clip per test
You get one of two things, never both:
- You mark your tests → one clip per test. Clicking a test on the session page jumps straight to its clip.
- You don't → one video of the whole session.
If a clip is missing, the page tells you so instead of spinning forever.
Espresso runs get one clip per test. A run that reports no tests (for example, when no test matched the filters) keeps a whole-session video instead. Video is on by default for Espresso; send video: false in the build to turn it off.
XCUITest runs get one clip per test too, taken from XCTest's own screen recording. Clips arrive after the run ends, and skipped or very short tests usually have none. Video is on by default; send video: false in the build to turn it off.
Headless sessions aren't recorded — there's no screen to capture.
Logs
Desktop browser runs slice their logs per test, the same way video does. Phone runs keep everything at session level, so you scroll rather than jump.
Android device logs are one dump taken at cleaning up, not a live stream. On a long run the phone's buffer can overwrite the earliest lines before we read them, so the start of a long session may be missing.
Watching a run live
Open a session's page while it is still running and the Live tab streams the browser, with logs and network ticking in as they happen. The tail starts when you open it — nothing is lost, because the full transcript is saved either way.
Naming and grouping runs
testkase:options.name— a label for one session.testkase:options.build— a CI run ID or commit SHA. Every session sharing one rolls up into an execution at /automate/browsers/executions.testkase:options.tags— free-form labels on the session row.
The search box on the session list matches name, build and session id — not tags.
Test history
Every session page has a History button. It answers the first question about a red build: has this ever passed, or has it been flaky for a fortnight?
- With a test selected, you get that test's history, matched by name across your organization.
- Otherwise you get the session's, matched by
testkase:options.name.
You see the totals and pass rate, the last ten verdicts oldest to newest, then one row per run — verdict, when, device, build, duration, who started it. Clicking a row opens it.
A run with no name has no history, because there is nothing to group it on. Set one and history accumulates from then on — it is not backfilled.
How long we keep it
Artifacts are deleted 30 days after the session — video, logs and test output alike. Every plan, every product, no exceptions. Download anything you need for longer. Uploaded app builds are separate, at 90 days.
That removes the files, not the run. Its verdict, timing, device and build stay on your dashboard, which is why history can show you runs far older than 30 days — you get the record without the recording.
Questions
▶My session has no video.
If it is older than 30 days, that is retention — the files are gone, the record stays.
If it is recent, check you set recording: true. It is off by default however you connect, and anything that isn't literally true counts as false.
▶I didn't set recording:true but I still got clips.
▶Where are the runs from one CI build?
Set testkase:options.build and they roll up at /automate/browsers/executions. Nothing in the navigation links to that page, so bookmark it.
▶Is the network capture a HAR file?
No — newline-delimited JSON. The only place TestKase produces a real HAR is Automate Mobile.
▶Can someone with a share link see my history?
No, by design. A share link grants one session; history would hand its holder a list of your organization's other runs. Someone reading a shared report sees no History button.
Troubleshooting
The XCUITest messages you are most likely to meet — features not available in a run, refused uploads, install failures, unknown devices, zero tests, timeouts — and what to do about each.
Sharing a session
Mint a public, read-only report link for an Automate Browser session — how links work, how to revoke one, and exactly what they do and don't do.