Who decides how long a hosted browser provider keeps your session recordings and logs?
answer
- the run ends, the copy does not
- not in your repository
- a variable, not a remembered fact
- a default nobody read
- or nothing expiring at all
basics
~20 sA hosted provider's own settings decide how long a run's recordings and logs survive, and usually nobody on your team chose them. Treat that keeping period as an account-level variable to establish per provider, not a remembered fact.
solid answer
~50 sThe keeping period for a hosted run's video and logs is set on the provider's side, as a property of the account and the product, and the team that wrote the suite usually never chose it. So the professional answer is not a figure but a method: **it is a variable you establish for this account**, and it can change without your release cycle noticing. Two failure modes sit either side of it. One is a period nobody read — a nightly mortgage pre-approval suite quietly accumulating recordings under a default. The other is that **nothing expires at all**: Selenoid, an unmaintained self-hosted grid, states in its own documentation that it has no built-in logic to remove old video files, so a team assuming a window there is assuming a feature. Until you have evidence, design as though the material persists.
go deeper
Be ready to say that a recording outlives the run and is stored by whoever runs the fleet. Knowing that the keeping period is somebody else's setting, and not your teardown code, is enough at this stage.
Be ready to explain where the keeping period lives — the product, the account, the agreement — and why none of the three is visible in a code review of your suite.
Be ready to describe how you would establish the value for a real account by observation and in writing, record it beside the suite, and re-check it, rather than carrying a figure in your head.
Be ready to argue what your organisation should require of a supplier here, and to design so that neither a short period nor no period at all creates an incident you cannot answer for.
## What the question is really testing An interviewer asking how long a hosted browser provider keeps your session recordings is not checking whether you memorised a schedule. They are checking whether you know **there is a schedule at all**, that it sits on the other side of a boundary you do not administer, and that nobody on your team is likely to have chosen it. The run itself is over quickly. The copy it left behind has a life of its own, and that life is a property of the account you rented rather than of the test you wrote. The honest professional answer is therefore not a figure. It is: *that is a variable, here is where it lives, and here is how I would establish it for this account.* ## Where the answer actually lives Three places, none of them in your repository: - **The product's behaviour** — what the provider records, and whether anything on its side removes material on its own. - **Your account's configuration** — whichever part of that behaviour a tenant is allowed to change. - **The agreement** — what the supplier has undertaken to do, which is the only one of the three with force behind it. None of those lives beside your tests, so none is covered by code review and none moves when your suite moves. That asymmetry is the lesson worth carrying: a change to your harness can alter **what gets captured from now on**, and can do nothing at all about **what was captured already**. ## Two failure modes, and the second one surprises people | failure mode | what it looks like | what it costs you | |---|---|---| | A period nobody chose | a default quietly applies; run material accumulates and expires on a schedule no one has read | evidence you needed is gone when you look, and material you never wanted kept was held meanwhile | | No period at all | nothing removes anything; the store grows for as long as the account exists | every run ever made is still there, including the nightly cycles that filled a mortgage pre-approval questionnaire | The second mode is the one people do not expect, and there is an open, checkable example of it. **Selenoid**, a self-hosted session-container grid that declares itself **unmaintained** in its own README, documents deletion as the operator's job: its video documentation states that it *intentionally has no built-in logic to automatically remove old video files*, and then offers the operator a scheduled sweep of old files, or a removal request sent per file, as the ways to bound storage. That is a deliberate design position, not an oversight. The generalisation to take from it is narrow, and it matters that it stays narrow: - **A run that assumes a retention window is assuming a feature.** - That statement is about Selenoid, which is unmaintained and open to read, and says **nothing** about what any commercial browser cloud does. - Asserting that a hosted provider never expires anything — or that it always does — would be exactly the kind of invented, fast-decaying claim this subject punishes. ## Establishing it instead of assuming it 1. **Observe what you can observe.** Make a deliberately disposable run, note the reference to whatever it produced, and check later whether that reference still resolves. That gives you a lower bound on the keeping period without you having to assert a policy. 2. **Ask in writing, and keep the answer.** An answer in a thread beats a memory, and an answer in the agreement beats a thread. 3. **Write it down where the suite lives.** A short note beside the test configuration saves the next person re-deriving it, and makes it reviewable when it turns out to be wrong. 4. **Re-check on a cadence.** A hosted product ships continuously and publishes no version you can pin, so an answer that was right when you wrote it is a claim with its own expiry. ## Designing for whichever answer you get - **Assume the material persists until you have evidence otherwise.** That assumption is cheap and it fails safe; the opposite assumption fails quietly. - **Keep what you genuinely need on storage you control**, so what must survive is not hostage to a schedule you do not set. - **Decide capture deliberately**, because how much accumulates is settled upstream, when somebody chooses between recording everything and recording on request. - **Treat every copy you pull out as a new keeping period**, because the provider's schedule governs the provider's copy and nothing else. - **Do not read "gone from the interface" as "destroyed"** — what a deletion request establishes is a separate, narrower question. ## The shape of a good answer in an interview Say that the keeping period is set by the provider and the account rather than by the suite; that it goes wrong in two directions, a default nobody read and no expiry at all; that Selenoid, unmaintained, is the open example of the second; and that the professional move is to establish the value for your own account, record it where the suite lives, and design so that neither answer hurts you. Resist the pull to supply a figure: a remembered number here is indistinguishable from an invented one, and your interviewer cannot check it either.
- How would you establish the keeping period for an account without asking the supplier?Observe it. Make a deliberately disposable run, keep the reference to what it produced, and check later whether that reference still resolves. Repeat it on a cadence. That yields a lower bound you measured rather than a policy you asserted, and it catches a change in behaviour that no one announced. It does not tell you what happens to copies you cannot see, so pair it with a written answer from the supplier.
- Why is 'we already have a retention policy in CI' not an answer to this question?A delivery pipeline's policy governs the artifacts that pipeline holds. A recording made by a hosted browser provider is held by the provider, under its own rules, and your pipeline's settings do not reach it. The two stores are separate, and only one of them is yours to configure.
- What changes about this answer when the fleet is one your team operates?The variable becomes yours. On a self-operated grid nobody removes anything unless you arrange it, so the keeping period is whatever your sweep or your teardown enforces, and the failure mode flips from a default you never read to an absence you never filled.
saying these in an interview costs you the question
- Quoting a specific keeping period from memory as if it were fixed
- Assuming every provider keeps run material for the same time
- Believing the test harness controls how long the far side keeps a file
- Thinking a recording disappears when the session that made it ends
- Treating the CI platform's artifact policy as covering provider-held material
- Assuming old artefacts always expire by themselves somewhere