The story below is an invented composite, assembled from situations that freelancers describe to each other, and any resemblance to a particular team is accidental. It follows three independent engineers who share a handful of retainer clients, and it asks a practical question that every solo operator eventually faces: what happens to a client’s infrastructure when the only person who understands it is ill? The answer, in their case, was a freelance DevOps runbook, and the way they built it is worth examining closely.
The setup: three freelancers, one fragile arrangement
Ines, Tomas and Priya had met in a community chat and started covering for each other during holidays. Each held two or three retainers: a subscription start-up, a small logistics firm, an online publisher. The arrangement was informal. If one of them was unavailable, another would “have a look” at the client’s systems. On paper, this was resilience. In practice, it was a gamble.
Covering for a colleague’s client meant logging into an environment you had never touched, with a brief that said little more than “everything is in the wiki”. When they looked honestly at the wikis, they found sparse notes, outdated diagrams and a few commands pasted without context.
The incident that exposed it
In March, Tomas came down with a nasty flu three days before a client’s quarterly infrastructure update. Priya agreed to run it. She followed his notes, which said: “update the cluster, then rotate the certificate, then run the smoke tests.” What the notes did not say was that the certificate rotation had to wait until the load balancer finished draining, a behaviour Tomas had learned from an earlier failed attempt and never recorded.
Priya rotated early. Thirty minutes of intermittent errors followed, the client noticed, and an apologetic call was required. Nothing was lost, but the client asked a fair question: would this have happened if Tomas had been there? Everyone knew the answer.
What the team did next: an evidence-led approach
Rather than jump to a solution, the three decided to look at what had actually gone wrong. They listed every recurring task across all six retainers and recorded, for each one, three facts: how often it happened, who normally did it, and whether a written procedure existed. The exercise took an afternoon and the result was uncomfortable. Of the recurring tasks, only a minority had any written steps, and nearly all of those had been written by the person who already knew the task.
They then ranked tasks by two criteria: how bad a mistake would be, and how likely it was that a stand-in would have to do it. The top of the list was predictable. Certificate rotation, database restores, quarterly updates and onboarding a new client’s access.
The method: capture, test, keep
Capture
For each top-priority task, the owner performed it live on a video call while a colleague typed what they saw into a shared document. The colleague was instructed to interrupt with “why?” whenever the owner did something without explaining. Those interruptions were where the unrecorded knowledge surfaced, including the load balancer drain that had caused the March slip.
Test
The second step was the one that made the difference. The colleague who had typed the notes did not run the finished page. Instead the third person, who knew nothing about that client, followed it cold in a staging environment while the others watched silently. Each pause produced an edit. The certificate rotation page grew three warnings in its first test and a decision point in its second.
Keep
Each page got a named owner, a “last proven” date, and a rule: whoever uses a runbook corrects it immediately if reality differed from the page. Updates were logged in two lines at the bottom: what changed and why.
The standard template they settled on
- Purpose and client. One line.
- Prerequisites. Access, tools, maintenance window, approvals.
- Steps. Numbered, with expected results and timing notes.
- Checks. How to know it worked, with specific places to look.
- Abort and rollback. When to stop and how to undo.
- Who to inform. Client contact and backup contact.
- Last proven. Date and tester.
The freelancer-specific wrinkles
Independent engineers face constraints that salaried teams do not, and the trio had to adapt the idea accordingly.
Confidentiality. The runbooks lived in each client’s own documentation space, not in a shared personal folder, so the client kept ownership and nothing sensitive crossed between retainers. Secrets were never pasted in; pages referred to the client’s vault.
Billing. Writing documentation takes time, and clients rarely volunteer to pay for it. The team folded it into the retainer as a stated deliverable, framed as insurance against exactly the kind of slip that happened in March. Two clients agreed readily. One needed a short conversation.
Many independent practitioners discuss these trade-offs when they talk about how to freelance responsibly alongside a day job, because responsible practice means a client is never left stranded by one person’s availability. A runbook is the cheapest way to honour that.
Trust between colleagues. The cover arrangement only works if peers can rely on one another. The same principle underlies building a dependable professional network: reliability comes from shared routines, not just goodwill.
One page, read aloud
An early tweak deserves a mention. After the second rehearsal, Priya suggested reading each finished page aloud before filing it. The effect was immediate: sentences that looked fine on screen turned out to be ambiguous when spoken, and steps that bundled two actions into one line were split apart. A step that cannot be read aloud in a single breath is usually doing too much. The habit cost ten minutes per page and removed a surprising number of small misunderstandings.
Results, honestly assessed
It would be convenient to report dramatic gains, but the trio themselves described the outcome modestly. Over the following months, no stand-in had to guess at a procedure. A cover shift that previously required a long briefing call now needed a short handover note listing only the live context. Two cover assignments ran with no contact at all with the usual owner.
They also noticed softer effects. The three felt able to take real time off. One of them later brought a new associate into a retainer and found the onboarding took days rather than weeks. And clients began to ask about the pages in sales conversations, which turned documentation from a cost into a selling point.
There were limits as well. A few judgement-heavy situations, such as deciding whether an odd traffic pattern was an attack or a marketing campaign, could not be reduced to steps. For those the team wrote short lists of opening questions rather than procedures, and accepted that some skill stays personal.
Where they looked for ideas
When designing the checks and rollbacks, the team read widely. For the data-heavy retainers, a blog that gets mentioned often in their circles is TheDataOps.org, which collects articles on moving from DevOps habits into dependable data work. They did not copy anything wholesale, but it helped them see how neighbouring specialists describe repeatable, checkable routines.
Lessons for other independents
- Start from evidence: list what you actually repeat, not what you think matters.
- Rank tasks by consequence and by the chance that someone else will have to perform them.
- Never let the author be the only tester of a page.
- Store documentation in the client’s own space, with secrets referenced rather than copied.
- Price the writing into the retainer and explain it as risk reduction.
- Treat every cover shift as a free test and correct the page afterwards.
The case is small, but the pattern generalises. Freelancers sell reliability as much as skill, and reliability cannot depend on a single person staying healthy. A modest library of tested pages is how three independent engineers made their cover arrangement into something clients could count on.
