The story below is invented. It is a composite sketch of the kind of contract that lands on a freelancer’s desk, with a made-up client and no real company behind it. It is here to show how PatchOps thinking changes the outcome of a short engagement, and where a solo contractor should draw lines. Names are left out on purpose: the freelancer, the client and the client’s one-person operations team are all you need.
The brief that looked simple
A small online retailer with around sixty servers hired a freelancer for six weeks. The request on paper was “get our patching under control before the peak season”. The retailer’s ops person was part-time, the previous contractor had left a spreadsheet, and the hosting provider’s console showed mostly green ticks. The freelancer’s first instinct was to ask what “under control” would look like on the last day.
That question is worth borrowing. It forces a measurable finish line, which the Ops Atlas describes in its entry on PatchOps as an enterprise patching vocabulary through a handful of metrics: on-time effective coverage, time to effective patch, share of unreporting assets, age of pending restarts and so on. The freelancer picked three of them and wrote them into the statement of work.
Week one: the inventory does not match
The spreadsheet listed sixty-one servers. The console showed fifty-four reporting. Four machines were named in neither. After a day of digging, two turned out to be retired but still billing, one was a forgotten staging box with a public address, and one was real and important: a reporting database nobody had touched in a year.
The freelancer did what any contractor should do first and wrote this down before changing anything. The Atlas, echoing NIST, warns against relying on periodic scans as an inventory method, so the fix was a small, owned list updated whenever a server was created or removed. The part-time ops person agreed to own it. That agreement mattered more than the list.
Week two: groups and the ring captain
Rather than inventing a grand scheme, the freelancer sorted the machines into four groups: web front ends, application workers, databases and the odd unmanaged leftovers. The ops person became the named ring captain, the one who could say yes or no when a rollout needed pausing.
Freelancers sometimes shy away from naming a client-side owner because it feels like handing work back. It is the opposite. A freelancer who leaves after six weeks needs someone inside the business who can keep the routine alive, a point the site makes elsewhere in its beginner questions for new DevOps freelancers.
Week three: the first ring and the first surprise
The first ring consisted of one machine from each group, patched on a Tuesday morning with a simple set of health checks. Web servers answered requests. Workers consumed queue items. The database passed its connection test. All green.
Two days later, a nightly export job failed on the canary worker only. A library had changed how it handled a time zone, and nothing the health checks covered would have caught it. Because the canary was the only affected machine, the cost was one retry the next morning instead of a failed export across the fleet. The freelancer added an export dry-run to the ring-one probes, a small change which the Atlas would call a functional probe: a check shaped by what the machine is for, not merely whether it responds.
Week four: restarts are where the lies live
When the freelancer recomputed coverage, the number dropped sharply. Eleven servers had installed the update but were still waiting for a restart, and the console had been counting them as done. The hosting dashboard was not lying maliciously; its definition simply differed from the one in the statement of work.
The contractor presented two figures side by side to the retailer: what the console reported and what counted as active after restart and still reporting. The gap was uncomfortable but led to a decision. Restarts would be scheduled for a quiet window at six in the morning, with a short announcement the evening before. Teaching a client that “installed” and “in effect” are different states pays off long after the invoice is settled.
The detour nobody budgeted for
Midway through the project the retailer’s hosting tool offered to upgrade one group of servers to a newer operating system release, labelled as a recommended update. The freelancer paused the rollout. The Atlas recounts a late-2024 episode in which one vendor’s newer server edition could install itself because metadata marked as optional was read by some tools as recommended, and the vendor later clarified how the flag should be interpreted. Major version jumps are a project, not a patch, so the freelancer blocked the upgrade class in the policy and logged the decision in the statement of work. A clause like that costs a minute to write and saves a weekend.
Week five: the emergency lane
The retailer’s anxiety was peak season. What if something serious was announced in the middle of it? The freelancer wrote a short page: who approves an urgent fix, which ring is compressed, how the first ring proves safety within hours, and how long reaching ninety-five percent coverage should take. Then they rehearsed it once on a harmless update. It took far longer than anyone hoped, mostly because two machines were unreachable, and that was precisely the lesson the drill existed to teach.
Week six: the handover pack
- The inventory and the rule for keeping it current.
- The four groups, their windows and their ring-one machines.
- An exception register where each entry had an owner, a reason, a mitigation and an expiry date.
- A one-page monthly report with the console figure and the honest figure side by side.
- The emergency page and notes from the drill.
Notice what is missing: any promise that nothing would ever break. The Atlas is sober about rollback, observing that on many platforms undoing an update is narrow or impossible and rolling forward to a newer fix is the usual recovery. A freelancer who promises zero incidents is setting up a dispute.
Lessons for the solo contractor
- Define finished in numbers. Without it, scope creep eats the invoice.
- Stay inside the lane. Deciding which vulnerabilities matter most, approving changes and enrolling devices are neighbouring jobs. Say who owns them.
- Leave a routine, not a heroic effort. The monthly rhythm of triage, daily checks during a rollout, weekly straggler chase and a monthly report survives your departure.
- Price the discovery. The week spent reconciling inventory is the cheapest insurance in the project, so charge for it explicitly.
Contract clauses worth borrowing
Three short clauses kept this engagement healthy, and they transfer to most small contracts. First, a definition of coverage that names the denominator, so nobody argues about it at the end. Second, a statement that the freelancer advises on cadence and mechanics while the client keeps decisions about risk acceptance, business freezes and exceptions. Third, an explicit note that the patching tool itself holds administrator rights everywhere, so access to it is granted narrowly, logged and removed when the contract ends. That last point surprises clients, yet a contractor with permanent rights over every server is a liability for both parties.
A word on balancing this with other work
Patch engagements are tempting for people running a second income, because the work is cyclical and predictable. Still, the habit of keeping honest records matters for the freelancer as well: the practical guide to a responsible DevOps side hustle makes the same point about boundaries and evidence. A clean handover pack protects you if something goes wrong months later.
The retailer got through the season without a patch-related incident. Whether that was skill or luck is the wrong question. What the freelancer actually delivered was a process that made luck matter less, and a document trail that showed it.
