This write-up was put together with help from Claude. If you can do the same without AI, then sincerely — well done, because I can't. An after-action review written by a backer, reconstructed entirely from public sources (the RSI status page and patch notes). No insider information. The aim is not to pile on CIG, but to isolate the mechanisms so they don't recur — a candid review, written in good faith and without imputing motive. That all of this can be reconstructed from the outside is, in itself, the point: these failure modes are visible, and therefore addressable. Edit — erratum (June 10, 2026). An earlier version claimed, in a methodology note, that patches 3.15–3.18 didn't appear in the status-page feed. That's inaccurate: they do — I had simply left them out of the comparison. Section 3 is corrected. Verified across the whole period: none of these patches exceeds 4.8 on maintenance (the worst 28-day window there tops out at ~7h, vs ~28h for 4.8). As for 3.18 — the roughest — it is in the feed, but its usable incidents there are sparse and mostly peripheral (launcher, bug-tracker); its game-service outages have no logged duration, and the feed massively undercounts its real weeks of trouble. What's certain: nothing close to 4.8's ~28h of maintenance. The post's conclusion is unchanged. Thanks to @CaptRubble for catching it. On §4 (for @Dr-Phibes). The cause analysis is an inferred reconstruction from the public timeline — status page (incident/maintenance timestamps and durations) + patch notes + the publicly-known DefenseCon coupling — not insider information. I also tested whether "event" or "patch complexity" predicts instability across the 25 majors since 2020: they don't — 4.8 is an outlier that neither variable explains as a trend. So §4 describes the 4.8 case, not a general law (correlation ≠ causation — a fair point raised by @Ventor-XLV). On §5 (communication). I've sharpened this point: it wasn't silence — CIG did post updates — but communication that was reactive and imprecise (maintenance overran with no public re-estimate; fixes were announced as deployed that didn't hold). The criticism is about the gap between what was announced and what actually held, not an absence of communication. (I've also corrected the LIVE date: May 14, not May 13.) 1. What happened Alpha 4.8 (a major patch, accompanied by a full economy wipe) went LIVE on May 14, coupled to the DefenseCon event (ship sales) and a Free Fly. The patch shipped unstable, required an unusual run of maintenances, and was still not fully stabilized roughly four weeks later. 2. The constraints — what is understandable Several decisions that drew criticism were, in fact, justified or unavoidable: The patch/event coupling wasn't a scheduling whim. The ships sold for DefenseCon (Ironclad, Hammerhead Gold Standard) were part of 4.8: the event depended technically on the patch shipping. That's a structural constraint, not negligence. The wipe was legitimate. It was an economy reset in response to a duplication problem, not a gratuitous wipe. The aUEC transfer cap (4.8.1) was the right priority. Limiting a duplication exploit — which corrupts persistent state irreversibly — ahead of recoverable gameplay bugs is correct incident triage. The Free Fly was protected. Rather than opening the doors onto a broken build, it was delayed and then suspended. Imperfectly, but the intent to limit the damage on the new-player side was there. 3. What the data shows (status page) In its first 28 days, 4.8 required 5 server maintenances totaling ~28 hours — the highest of any patch since 2020, and by a wide margin (~3× the next-highest). Server-maintenance downtime per patch, every major since 2020. 4.8 (in red) ≈ 3× the next-highest. An important and honest caveat: it's not that the game collapsed. Actual outages stayed modest (~4.5h). It's that it took continuous intervention to keep it running. So the signal isn't "catastrophic instability" but "exceptional intervention load" — compounded by a stabilization that is dragging. Worst patches by logged game downtime (service incidents, not the lived gameplay experience). 4.8 is almost all maintenance (blue); all the others at the top (3.24, 3.10, 4.5, 3.20, 3.12) were unplanned outage (orange). What about the intermediate patches? The comparison is between major patches, each measured over its first 28 days (point-releases like 4.8.1 are counted within their major's window). I checked the 3.15–3.18 era: nothing there exceeds 4.8 on maintenance. An acknowledged limit of the feed: the status page measures service availability (login, servers up), not playability. Patches known to be rough but where the servers "held" — 3.18 (PES), 3.23 (Master Modes), 4.0 (server meshing) — show up low here, even though the lived experience was far worse (bugs, desync, broken missions). That's exactly why I compare maintenance: it's planned, always logged start-to-finish, and so escapes this undercounting. 4.8's ~28h is itself a lower bound (one maintenance with no usable duration isn't counted). 4. Cause analysis Root cause (structural). Tying ship-sale revenue to the patch's release date removed the one margin that matters: the ability to ship only when it's ready. Aggravating factor — scope. A heavy technical scope (the Transport System rewrite, new multi-grid ships, several T0 systems) means a large bug surface. Aggravating factor — load, and the PTU blind spot. Record concurrency, which CIG itself described as severe system stress. And this is the answer to "but there was a PTU": server-stability problems under real load are precisely the class the PTU — which runs at a fraction of the LIVE population — cannot reproduce. A "clean" PTU therefore doesn't guarantee a stable LIVE, hence the need for a stabilization buffer on LIVE before committing the event. Hypothesis on handling. Running a major patch, a commercial event, and a Free Fly at the same time likely stretched the capacity to anticipate — which shows in the Free Fly being delayed then suspended under pressure, and in announced maintenance windows not being met. (A hypothesis about coordination, not a personal accusation.) Both an accident and foreseeable. The specific bugs are contingent; that instability of this kind would arise under these conditions was foreseeable. The accident is the outcome; the conditions that made it likely were choices. 5. The mistakes worth not repeating Stated plainly, as process choices — not individual failings: Placing a major patch's LIVE release on the critical path of a commercial event. That is what turned a marketing event into a technical deadline, and removed the option to slip. Communication during the incident. The Free Fly was suspended with no ETA; the maintenance was announced at 6h and overran (~12h) with no real-time public re-estimate; and fixes were announced as deployed that didn't actually hold (docking, MobiGlas routes flagged as "fixed" but still broken). The problem isn't total silence — CIG did communicate — but communication that was reactive and imprecise: it's that gap between what was announced and what was actually lived that costs the most in perception, and it's entirely avoidable. Timeline of server interventions over 28 days (bubble size = duration); the two large early-June bubbles are the long maintenances — i.e. ~3 weeks after launch. Even stronger alternative here: your own status-page screenshot (the June 9 incident, the overrun 6h window). 6. Recommendations Decouple major-patch LIVE releases from the commercial-event calendar — or gate the event's launch on a stability threshold actually being met, not on a marketing date. Guarantee a minimum communication cadence during incidents — a regular status update, even "no ETA at this stage," and maintenance windows that are either honored or publicly re-estimated. In one sentence 4.8 did not suffer the longest outages in the game's history; it demanded the most server intervention. The cause isn't an isolated bug but two process choices — commercial coupling and incident communication — that will recur at the next major patch tied to an event unless they are addressed. To be clear I'm not writing this out of anger. I'm backing an alpha with eyes open: instability is part of the deal, and I signed up for that. But alpha status covers the bugs, not the process choices around them — the commercial coupling, the communication. If I'm taking the time to write this up, it's precisely because I want the project to succeed; and a reasoned piece of feedback deserves to be weighed, not waved off with "it's an alpha."