Asking for forgiveness does not work when the infrastructure goes dark
On December 24, 2019, I posted on Twitter the photo at the top of this article. It was Christmas Eve, and I was watching the monitoring screens. As CTO, I was responsible for all Visa transaction processing in Uruguay, and we were still stabilizing an operation that struggled for years. To pass those hours, I printed a report from the UK House of Commons Treasury Committee: IT failures in the Financial Services Sector.
The committee published that document in October 2019 after several severe banking outages in the UK. One of them was the 2018 TSB incident, where a failed migration locked millions of customers out of their accounts for weeks. None of what Parliament found was a mystery. They saw legacy systems where the engineers who understood them retired, and rushed changes where teams compressed testing to meet deadlines. They also flagged third-party dependencies with no recovery plans, and high concentration in a few cloud providers.
Almost seven years later, three news stories from the past week show that every warning in that report still stands. They also show the limit of a rule I rely on: it is easier to ask forgiveness than permission.
What one week revealed
Last week, Mastercard announced mandatory offline payments across Europe. The mandate starts in February 2027 for new cards, and in May 2027 for new or replacement terminals. The mandate follows the April 2025 power blackout in Spain and Portugal, which left about 55 million people unable to make digital payments. When power fails or a network link drops, people still need food, fuel, and medicine. A global card network that stores spending limits on the chip again to approve local transactions up to EUR 200 is a wake-up call. The permanent connectivity we take for granted does not exist.
Revolut suffered a worldwide outage on Tuesday, October 20, for several hours. Millions of users across Europe and Japan could not open the app or pay with their cards. Revolut is not a traditional bank tied to a 1980s mainframe. It is a fintech valued at USD 115 billion, serving more than 80 million retail customers. Later that evening, the company explained on X what caused the disruption. A power event hit a Google Cloud data center near London. That is the exact concentration and third-party risk the UK Parliament warned about in 2019. For a customer standing at a supermarket checkout with a declined card, knowing that the cloud provider failed changes nothing.
The PHP project published a critical security advisory yesterday, October 21. It fixes two vulnerabilities: CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10 on CVSS v4.0. An out-of-memory condition and stale worker state allow unauthenticated remote code execution. The release triggered simultaneous warnings around the world, from the UK NCSC to CERTuy in Uruguay. The flaws affect every PHP release, but the official releases only cover supported branches (PHP 8.2 through 8.5).
That is where the security advisory meets production reality. According to W3Techs data for October 2026, almost half of all PHP websites run end-of-life branches. About 27% still run PHP 7, nearly 8% run PHP 5, and another 14% sit on PHP 8.0 or 8.1. The PHP team even published emergency source backports for 7.4, 8.0, and 8.1 on GitHub, because official builds no longer exist for them. For releases older than those, no point update exists at all. Patching means migrating a runtime under fire. The NCSC guidance is blunt. If an organization cannot update or mitigate in time, it should consider taking the system offline. If it cannot shut the system down, it must inspect the host for compromise and backdoors before upgrading.
Anyone who works in operations knows what happens when an alert like this lands. A post on X by @IT_unhinged captured it yesterday with dark humor: security calls at 6:12 AM ordering an immediate patch on every PHP server. According to the inventory, there are twelve. According to reality, nobody knows. And once teams find them, including third-party appliances that bundle PHP inside, many run versions that lost support years ago.
The three I picked are not the whole picture. The same week brought Oracle’s October Critical Patch Update, with fixes across Java SE. Forty-nine of them cover flaws that may be exploited remotely without authentication. Node.js shipped security releases on Wednesday for the 26.x, 24.x, and 22.x lines, covering OpenSSL, Undici, c-ares, and SQLite. The list keeps growing, and the volume is exponential. Our capacity to absorb it is not growing at the same speed. Advisories now arrive faster than most teams can read them, let alone patch.
This is why I insist on living documentation for production systems. A diagram drawn by hand to pass an audit becomes false the following week. Earlier this month I wrote about architecture as code and the FINOS CALM standard. When the architecture model lives in the repository and validates in the build, you know what components you run and how they connect. You do not have to guess what runs where in the middle of an incident.
Why adding a new window takes so long
Look at those three fronts together: physical networks that drop, cloud regions that lose power, and base software that ages out of support. The obvious question is why our platforms stay so fragile.
The cause is rarely technical. In most organizations, the business pushes every day for new features. That pressure is easy to understand: a new feature is visible, sells well, fits on a board slide, and has a clear return. Operational continuity, risk management, and paying down technical debt remain invisible as long as the lights stay on.
Cartoon by Vincent Déniel (@vincentdnl), via Chris Fenning: “I don’t understand why it takes so long to add a new window.”
That cartoon sums up conversations I have had dozens of times. From the outside, nobody understands why opening a new window takes so long. Nobody looks up at the umbrella over the hole in the roof or at the beams that keep the cracked wall standing. They only want the window.
Keeping critical systems alive takes unglamorous work. Teams have to update dependencies, test link failures, document systems so knowledge does not sit with one person, and clean up old code. I made that case for the Uruguayan Engineers Association magazine and in a talk at ORT University, both in Spanish. The cost of doing nothing is never zero. It compounds quietly until the full bill arrives at once.
Where asking for forgiveness stops working
I agree with the line popularized by Grace Hopper: it is easier to ask forgiveness than permission. The US Navy rear admiral and COBOL pioneer gave that advice to engineers dealing with institutional inertia. To cut through bureaucracy, test a prototype, or move a project stuck in meetings, pushing ahead is often the only way forward. I used that rule more than once in my career, and I also paid for my own mistakes when I moved too fast.
But that rule does not apply everywhere. In critical infrastructure, it hits a hard wall, because some failures cannot be undone.
If a payment rail fails, a breach exposes data, or a bad migration stops operations for days, an apology on social media fixes nothing. The bill comes in direct financial losses, regulatory fines, and reputational damage that takes years to recover from. The trust of the people who put their money or their daily operations on your platform takes decades to earn and one afternoon to lose.
The same logic applies to how we use artificial intelligence today. A meme making the rounds on X calls it the “vibe tax”. It shows a price list: USD 500 for manual coding, and USD 8,000 when someone must review vibe-coded work. Generating code or text without understanding what goes into production only builds technical debt faster.
The “vibe tax” price list shared on X.
I wrote this article with AI assistance1. What matters is the boundary: the stories and opinions here come from experiences I actually lived through, suffered, and enjoyed across my career. I review the result, question the sources, and take full responsibility for what carries my name. Whether it is a blog post or a change in production, you can delegate the drafting, never the accountability.
The project I spend my open-source time on, fluxrig, starts from that same premise. It is a universal protocol orchestrator, built on NATS for active-active messaging across regions. I aimed it at payments first, but the same design fits IoT and any system where the link can drop. It keeps decision-making close to where the work happens and treats the cloud as a dependency, not a guarantee.
Commercial speed only works when the floor underneath is solid. Putting operational continuity, resilience, and the orderly retirement of obsolescence on the table does not slow the business down. It makes sure there is still a business tomorrow.
At JAAB, we help teams manage operational risk and modernize critical platforms without reckless rewrites. If you are dealing with systems that nobody wants to touch but your entire operation depends on, get in touch.
I drafted this post in OpenCode, orchestrated through Paseo. The prose review ran on a different model, against the ASD-STE100 skill (standard). ↩︎