On a rented browser fleet, why must a failing run's evidence be arranged before the run rather than after it?

## Investigation on a machine you administer When a suite fails on a fleet you run, the failure leaves an object behind. There is a host with a name. There is a container that may still be up. There is a service log on disk, a browser profile, perhaps a core file. You can log in. You can hold that machine out of rotation and re-run the case against exactly it, with a debugger attached if you want. Every one of those moves rests on a single fact: **the machine is an asset you administer.** Reachability is not something you thought about, because it was never in question. ## Investigation on a machine you rent A rented fleet removes that asset, and it removes it completely rather than partially. The session ran on a host you have no account on. It ended when your run ended. There is no shell to open, no log directory to read, no container to keep alive "just for a bit", and no way to go back afterwards and ask for something nobody captured while it was happening. What survives a rented run is a short list, and it is worth being able to recite: - **What your side sent.** The request that created the session, the commands that followed, and their timings. - **What your side recorded.** Assertion output, whatever your harness captured at the moment of failure, and the identifiers that name this particular run. - **What the far side kept.** A provider commonly records something about a session without being asked, and that record can usually be retrieved afterwards. What a given provider records, and how long it keeps it, is a property of that provider: establish it, do not assume it. - **Nothing else.** Anything outside those categories did not survive the run, and no amount of asking afterwards creates it. ## Why that inverts the discipline On your own fleet, evidence gathering is a **response** to a failure. You see red, you go and look. The looking happens after, on a thing that is still there. On a rented fleet, evidence gathering is a **precondition** of the run. The failure and the disappearance of the machine are the same event, so anything you did not arrange to keep is simply gone. This is not a difference of emphasis; it is a different order of operations, and it is the commonest way a team gets less out of a hosted fleet than it paid for. ## What "arranging it in advance" concretely means 1. **Capture the identifiers that make a run nameable.** A conversation with a provider about "last night's failure" goes nowhere; a conversation about a specific run has somewhere to start. Those identifiers exist only while the session is alive unless your harness writes them down. 2. **Record what you asked for and what you were given.** The requested target and the environment the created session reported back are the only description of that machine you yourself will hold. 3. **Make the harness capture at the moment of failure, not after it.** Whatever your framework collects on a failing case is collected while the session still exists. A collection step that runs after teardown collects nothing. 4. **Make teardown record the outcome rather than exiting silently.** Teardown is the last code that runs with the session still open; it is the last chance to note anything. 5. **Know, before you need it, what the provider keeps and for how long** — by asking and checking once, rather than assuming a retention window exists. ## The hedge that keeps this honest "You get nothing back from a rented fleet" is as wrong as "you can just go and look". A hosted provider typically retains a record of a session it ran, and retrieving that record is a real and useful capability — it is one of the things renting adds rather than takes away. Two things about it are nonetheless true at once, and a strong answer holds both: - It is **the provider's record, on the provider's terms.** You did not choose what it contains. - It is **closed to additions after the fact.** Whatever it holds is what it holds; nothing you realise the next morning can be added to it retroactively. So the pre-arranged half of the evidence is the half you actually govern, and that is why it deserves the design attention. ## Working it through on a real suite Take a regional railway's seat-reservation site. A booking case fails at the seat-map step, at night, on a rented fleet. Ask yourself, before the run rather than after it, what you would want in your hand at nine the next morning: - The application build under test and the fixture data the case used — yours, if you recorded them. - The target requested and the environment given — yours, if the harness wrote them down. - Where in the case it failed and what the page looked like then — yours, if capture is wired into the failing path. - The run's identifiers, so you can ask the provider about that run — yours only if captured while it lived. - Anything about the host itself — not yours, beyond whatever the provider chose to keep. The first four are design decisions you make once. The last is the one you accept. That asymmetry, and not any particular tool, is what changes when the machines stop being yours.