Patch day: what actually happens between a game update and your build coming back online

"The game updated, when will it be back?" is the most common message in our Discord, and the honest answer is "it depends on what they changed". This is what actually happens in between, using a real Squad patch as the example.

03:12 — the monitor fires

We run a small fleet of machines that do nothing but check whether the games we support still match our expectations. Every fifteen minutes, each one verifies the game build id and re-resolves a handful of critical offsets.

At 03:12 the Squad checker reported a build id change and three failed offset resolutions. That fires an alert into our dev channel automatically.

03:14 — status goes to Updating

The status change is the first thing that happens, before anyone even looks at the patch. A developer — or in this case the monitor itself — posts to the dev channel:

Squad -> Updating

That message is picked up by our Discord bot, written to the database, and pushed to every open browser tab through a live connection. Within about two seconds the status page shows Updating, the product page shows Updating, sales pause, and the loader begins refusing to inject.

Nobody edited a webpage. That is the entire point of the integration — the gap between "we know" and "you know" is measured in seconds, and it does not depend on someone being awake to update a site.

03:40 — first look

A developer picks it up. The first question is always the same: is this a content patch or an engine recompile?

• Content patch — new map, balance changes, no code recompile. Offsets are mostly intact. Turnaround measured in an hour or two.
• Engine recompile — everything moves. Turnaround measured in most of a day.
• Anti-cheat update — the serious one. Turnaround depends entirely on what changed and is genuinely unpredictable.

This one was a recompile with an EAC module bump alongside it. Worst realistic case short of a targeted detection.

04:05 — offset resolution

Offsets are found with signature scanning: search the new binary for byte patterns around the code that references each structure we need, then resolve the address from there. Most patterns survive a recompile. Some do not, and those get rebuilt by hand from the disassembly.

For this patch, 31 of 38 signatures resolved automatically. Seven needed manual work, of which two were genuinely painful because the surrounding code had been restructured by the optimiser rather than changed by a developer.

06:20 — structure verification

Resolving an offset is not the same as it being correct. A signature can resolve to the right instruction while the structure it points into has had a field added, shifting everything after it.

So every structure gets verified against live game state: load a match, read the fields, confirm health reads as a number between 0 and 100 rather than 1.4e-42.

Two structures had moved fields this patch. The pawn structure gained four bytes ahead of the bone array, which shifted every skeleton read. That is the kind of thing that produces ESP skeletons drawn as abstract art, and it is why verification exists.

07:45 — ballistic re-verification

Squad's patch notes mentioned weapon handling changes, which means the ballistic tables need re-measuring rather than assuming.

This is tedious and unglamorous: fire each affected weapon at measured ranges on an empty server, record impact points, fit the curve, compare to the stored table. Eleven weapons changed enough to need new entries.

We do this every time weapon handling is touched, because an aimbot working from a stale ballistic table misses in a way that looks like the product is broken.

08:30 — anti-cheat surface check

The EAC module bumped, so the next question is whether anything we do has become visible.

The test fleet runs the rebuilt payload against the new EAC across several hours and several matches, on accounts that exist for exactly this purpose. What we are watching for: new scan patterns, changed callback registration, and any behavioural difference in how the anti-cheat responds to our driver's presence.

Nothing new this time. When there is something new, this is where the timeline stops being predictable — hardening against a new detection method can take a day or a week, and we would rather say that honestly than ship on a schedule.

09:15 — build, sign, publish

The payload is compiled per-user with randomised layout, the manifest is updated, and the new build is published to the loader API.

Then a developer posts in the dev channel:

Squad updated to v2.4.1
- Rebuilt for game build 8.2.1
- Re-measured ballistic tables for 11 weapons
- Fixed skeleton offsets after pawn structure change
- Verified against new EAC module

The bot parses that, writes a changelog entry, and it appears simultaneously on the changelog page, the Squad product page, the Latest Updates section on the home page, and every customer dashboard. Again — nobody edited anything.

09:17 — status back to Undetected

Squad -> Undetected

Sales resume. The loader injects again. Every open browser tab updates without a refresh.

Elapsed: six hours and five minutes from the monitor firing.

09:20 — credit applied

Every active Squad subscription is extended by the downtime. Six hours rounds to a day, and a day is added to every affected licence automatically. Nobody opens a ticket and nobody has to ask.

This is not generosity, it is just the correct behaviour: you paid for days of access and you did not get one of them.

Why we built the Discord integration

For a long time this process had a manual step: after fixing everything, someone had to remember to update the website. Which meant the website was reliably wrong for the first hour of every incident — the worst possible hour.

Now the source of truth is the place the work actually happens. A developer types Squad -> Updating in the channel they are already in, and the site is correct two seconds later. The changelog writes itself from the same messages.

The failure mode we designed out was "the developers knew, but the site did not say so." That gap is where people get banned.

What you can do on patch day

• Check the status page before you launch anything. It is live.
• Do not try to force injection. The loader blocks for a reason and there is no override.
• Do not ask for an ETA in the first hour. We do not have one yet, and the honest answer is always in the dev channel first.
• Watch the changelog. When the entry appears, the build is live.

Frequently asked questions

Why can't you have the update ready before the patch? Because the patch does not exist until it ships. We cannot resolve offsets in a binary we do not have. Occasionally a patch is playable on a public test branch first and we get a head start — that is why some updates land in under an hour.

Do I lose days from my subscription? No. Downtime is credited automatically.

What if it takes several days? Then it takes several days, and we say so in the dev channel. If a build is down more than 48 hours you can request a refund or a credit under the refund policy, and we will not argue about it.

How do I get notified? Turn on notifications in the dev-log channel in Discord, or subscribe to the newsletter in the site footer.

Watch it happen live on the status page, or read every update we have shipped on the changelog.