Why Your Apps Keep Breaking

On the morning of September 3, 2026, users checking their Taobao order histories saw a spinning wheel. The error message read: "Network crashed."

The hashtag "Taobao down" climbed to number one on Weibo. Customer service offered the standard script: clear cache, check your network, we've reported it to our engineers. Hours later, the official line landed: "The system had a minor glitch. It is now restored."

That could have been the end of it. But these glitches have been clustering, shift after shift.

Between 2025 and 2026, Meituan, Xiaohongshu, Zhihu, Burger King, KFC, and Douyin—three times—all went down. In the days just before Taobao's failure, Maoyan FM and Shanbei Words crashed in sequence. The calendar reads like an on‑call rotation.

On Weibo, a user posted a split‑screen screenshot: the recommendation feed, still showing sneakers they had searched hours earlier, and the order page, blank. A reply to that post read: "The part that takes your money is broken. The part that tries to sell you more is still running." That reply gained 20,000 likes in under ten minutes.

On Maimai, the anonymous corporate forum, threads filled with numbers. One post: "Our team went from 12 people to 4 in one year." Another: "We outsourced operations. The new hires don't even know which server holds the database credentials." Neither post was rebutted. Each drew hundreds of replies—all agreeing, none defending the change.

The replies sketched a shared picture. Teams shrank. Code reviews, once signed off by three engineers, now required only one. That one reviewer was often a manager who had not touched the production environment in over a year.

Here is how that plays out in practice.

A junior engineer writes a change to a gateway routing rule. It looks harmless—a tweak to time‑out values, from thirty seconds down to ten. The old process would have sent it to a senior engineer who knew exactly how the downstream database behaved when time‑outs shrank. That senior engineer left six months ago. The only reviewer left approves the change without a second look. It goes live at 9:15 AM.

At 9:47 AM, the new time‑out fires on a cluster of slow queries. The connection pool to the order database fills with hung sessions. New requests queue. The frontend shows a blank white page. Users start refreshing—and each refresh adds another retry. Within minutes, the retry storm multiplies the original load by a factor of thirty. Services that were not part of the change also begin to fail, because they share the same database pool.

That is the cascade. One config tweak, no qualified reviewer, and a thirty‑two‑minute outage.

By 3 PM that day, order pages loaded again. The hashtag slipped off the front page, replaced by fresher topics. Customer service left one line pinned: "The system had a glitch. It's back to normal." No timeline. No root cause. No follow‑up.

Why do these breakdowns happen so often now?

Look at the incentives. System stability has a cruel logic: the longer it holds, the more its guardians look like they are doing nothing. Unused capacity looks like waste. A standby data centre looks like redundant expense. An engineer monitoring legacy middleware looks like overhead.

Consider a site‑reliability engineer who spends a week fixing a subtle memory leak in a caching layer. She writes a two‑line patch, tests it, deploys it. No one notices. The dashboard stays green. To the finance director, her output looks indistinguishable from an idle employee's—she launched no feature, she acquired no user. But that memory leak, had it reached production at scale, would have taken the cart service offline for six hours. Those six hours never happen. No one can point to a thing she did and say, "This saved us."

On a balance sheet, her salary is a visible cost. A disaster that never happens is an invisible benefit—one most managers never see.

So cuts come. The finance team trims "non‑core" roles. Leadership keeps the people who pitch AI roadmaps and user‑growth numbers. Review processes thin from three sign‑offs to one. On‑call rotations stretch from twelve engineers to four, then from four to two.

No single decision was incompetent. Each was rational, considered, defensible.

The chief financial officer's bonus is tied to EBITDA and cost per user. Trimming operations lifts both metrics—immediate, measurable, and visible in the quarterly presentation. The chief product officer's bonus is tied to monthly active users and feature adoption. Neither compensation plan contains a line for "prevent a forty‑five‑minute outage." The cost of a breakdown does not appear on the P&L until after it happens. By then, the news cycle has moved on.

So the decisions that look sensible in a spreadsheet—cut the SRE team, push reviews to one sign‑off, skip the full regression test—are not stupid. They are structurally encouraged.

The dark turn is not a villain. It is a structure.

For context: during Singles' Day in 2018, traffic dwarfed the morning of September 3, 2026. Afterward, engineers produced a postmortem hundreds of pages long—naming root causes, assigning owners, spelling out fixes.

The review happened in a war room. Projectors showed timelines. Teams from database, networking, and frontend sat together through the night. Someone ordered pizza. The final document ran over three hundred pages. It included a table of every single action taken in the first fifteen minutes, timestamped and attributed. The culture treated that document as a debt to be settled.

In 2026, a routine Tuesday morning broke the order service. After recovery, there was no report. The postmortem was a Slack thread. Three engineers discussed the config change. One typed "reverted." The thread was archived five days later, unread by anyone outside the direct team. There was no presentation. There was no table. The debt was not settled; it was ignored.

Two time points, placed side by side. No conclusion needs to be stated.