In 2026, China saw a run of large-scale system failures across very different sectors: AI services, cloud computing, securities trading, event ticketing, and telecommunications. Each one spread quickly across social media and drew intense scrutiny from users and, in some cases, regulators.

In this article, we look at five outages that occurred in China in 2026 and examine each one from four angles: what happened, the impact, the cause, and the key issues it raises. Many of the companies involved have not disclosed detailed root causes, so the analysis below is limited to what official statements and media reports make available.

Case 1: DeepSeek, a seven-hour outage of a generative AI service (March)

When

Evening of March 29 to the morning of March 30, 2026　／　Sector: Generative AI chatbot

What happened

The chatbot service run by Hangzhou-based AI company DeepSeek went down on the evening of Sunday, March 29 and stayed down into the next morning. According to media reports, the company’s status page acknowledged the problem at around 9:35 p.m. and marked it as resolved roughly two hours later. The service, however, did not actually recover, and the company went on to roll out several more fixes. The status page ultimately classified the event as a “major outage” lasting 7 hours and 13 minutes, resolved at 10:33 a.m. local time on March 30.

Impact

The consumer chat interface was unavailable, and during peak hours some users reportedly could not access their saved conversation history either. The outage tracker StatusGator logged 428 user reports within 24 hours. Developers and businesses that rely on DeepSeek for their work were also affected, and some users posted on social media that they had only realized how dependent they were once the service was gone. It was the first time the consumer chat interface had been down for more than two hours since the company’s rapid rise in early 2025.

Cause

In line with its usual practice, DeepSeek has not explained the cause. Reuters noted, in general terms, that outages like this can stem from anything from server malfunctions to bugs introduced by an update.

Key issues

The fact that the outage continued after being marked as resolved shows how fragile an initial assessment can be. And when a service announces recovery without explaining what went wrong, companies that have built its API into their own operations are left with nothing to tell their own customers. As AI becomes part of business infrastructure, the question of how AI providers should disclose information during an outage is likely to become a business continuity issue for the companies that use them.

Case 2: Kaiyuan Securities, a data center network failure and a delayed report (April)

When

April 20, 2026 (regulatory action in August)　／　Sector: Online securities trading

What happened

At Kaiyuan Securities, a brokerage headquartered in Xi’an, a network communication failure occurred at a Xi’an data center (operated by the carrier China Mobile) that hosted a trading site for the firm’s trading app. About four months later, in August, the Shaanxi bureau of the China Securities Regulatory Commission issued the firm a formal warning letter and entered it into its compliance record. The regulator set a deadline for a written remediation report and said it would verify the fixes through an inspection.

Impact

Some users were unable to log in to the app, which disrupted normal trading. The number of affected users and the length of the disruption have not been disclosed.

Cause

The technical trigger was a network failure at the data center, but no further detail has been made public. The regulator’s remediation requirements, however, point to where the weaknesses likely were: maintenance of critical equipment, optimization of communication protocols, and automatic failover of client connections to other sites.

The direct reason for the regulatory action was something else entirely: the firm did not report the incident promptly, as required. In China’s securities and futures industry, firms must report immediately when a system failure may qualify as a cybersecurity incident, and for the most serious incidents they must provide status updates at least every 30 minutes until service is restored. According to media reports, more than ten brokerages have now faced regulatory action over system failures, late reporting, or concealment.

Key issues

What regulators targeted here was not the technical recovery but a failure in the reporting process. At many financial institutions, it remains unclear who decides an incident’s severity, on what information, and when reporting should begin. The more a team is absorbed in recovery work, the more easily reporting slips down the list. It may be worth rethinking the assumption that incident response and incident reporting are separate jobs.

Case 3: Damai, a ticket sale postponed due to human configuration error (July)

When: July 20, 2026　／　Sector: Concert ticketing platform (part of Alibaba Group)

What happened

At 10 a.m. on July 20, Damai, one of China’s largest ticketing apps, opened sales for a music festival in Kunshan, Jiangsu Province. The event was highly anticipated, with more than 150,000 users having marked it as “want to see,” and the sale was an early-access window reserved for members of Alibaba’s paid membership program, 88VIP. Problems began immediately after sales opened. Damai apologized and postponed the sale to 10 a.m. the following day.

Impact

Users reported pages freezing, blank white screens, and unresponsive buttons, and some said not a single payment went through. Some 88VIP members were also told they were “not 88VIP” members and could not buy tickets. On top of that, while the sale was pushed back by a day, the deadline for free cancellations stayed the same, cutting the cancellation window for general buyers from 48 hours to 24. In the same week, Damai also faced separate purchase complaints over another concert, further denting user trust.

Cause

Damai attributed the problem to “human configuration error.” Some industry insiders, however, said it is rare for a configuration error to cause this level of disruption, and suggested the organizer may not yet have finalized its ticket allocation.

Configuration-related problems have recurred at Damai. In June 2025, a staff member set the wrong time for a priority purchase window, and the platform had to refund more than 6,700 orders. In January 2026, a configuration error allowed tickets to be sold before the announced sale time.

Key issues

Configuration changes are more likely than code changes to slip past review and testing. Settings that can only be validated at the exact moment they take effect, such as a sale start time, call for especially careful double-checking and pre-production simulation. It is also worth noting that the handling of compensation and refund terms after the outage amplified user frustration. Incident response arguably needs to include what happens after recovery, not just the recovery itself.

Case 4: Shanghai Telecom, a wide-area outage of fixed and mobile networks (August)

When

Around 8:30 p.m. on August 30, 2026　／　Sector: Telecommunications carrier (critical infrastructure)

What happened

A network failure hit the Shanghai unit of China Telecom, centered on parts of the city’s Jiading District. The company said that after emergency repairs, service began returning from around 9:20 p.m., and it issued an apology.

Impact

Fixed broadband connections dropped, and 4G and 5G mobile service went down as well. People working from home and people trying to pay with smartphone QR codes, a common payment method in China, suddenly found themselves offline, and complaints and questions flooded social media.

According to some reports, the customer service hotline was hard to reach and the carrier’s app could not accept fault reports because of congestion. The initial automated phone message also reportedly described the problem as affecting fixed broadband only, which led users to underestimate its scope.

Cause

The root cause has not been disclosed, and no compensation plan had been announced at the time of reporting.

This was reportedly Shanghai Telecom’s third large-scale outage in about two years. In August 2024, its cloud broadband service suffered widespread problems, and in the early hours of March 31, 2026, a citywide outage affecting districts including Pudong, Baoshan, and Yangpu cut connections for between 20 minutes and an hour.

Key issues

When critical infrastructure fails, the channels for communicating with users can fail at the same time as the service itself. Issuing a first notice before the scope is understood, and then having to correct it, erodes trust further. In situations like this, a practice of continuously updating what is known and what is not yet known, even when the information is incomplete, is likely to make a real difference.

Case 5: Tencent Cloud, a metering bug that led to a false bill and a 17-hour service suspension (October)

When

October 3 to 4, 2026 (during China’s National Day holiday)　／　Sector: Cloud billing platform

What happened

At 6 a.m. on October 3, a Tencent Cloud customer received a notice that their account was about 50,000 yuan in arrears, and their service was suspended as a result. Customer support initially offered a 100-yuan voucher as compensation and later raised it only to 300 yuan, prompting the customer to share the story on social media, where it drew wide attention. On October 7, Tencent Cloud published an explanation and apology through its official account.

Impact

The customer’s service was suspended for about 17 hours. According to the company, the bill existed only as a billing record and no money was actually taken from the customer. The amount the customer had paid to clear the supposed arrears was refunded, and service was restored at 11:36 p.m. on October 4.

Cause

The technical cause was a unit conversion defect in a specific metered item of a serverless development product. Under extreme conditions, usage was overstated, generating an abnormal bill of 50,420.74 yuan. The company said it deployed a fix on October 4 and also checked historical data.

The reasons the response took so long, however, were organizational. According to the company, identifying the root cause took about five hours, and the initial investigation stayed at the level of the bill itself. The product development team only got involved after the customer provided further evidence. The company also cited the National Day holiday as the main reason recovery took so long, because its approval workflow slowed down. Tencent Cloud acknowledged that it should have restored service as soon as it confirmed the problem was on its side, and said it would set up an emergency approval channel for holidays.

Tencent Cloud had also experienced login failures twice in a single day in April, affecting its AI development tools.

Key issues

This case is a clear example of escalation paths and approval processes, rather than the technical fault itself, becoming the bottleneck. While front-line support treated the issue as a billing matter, the information never reached the development team, and even after the cause was found, recovery waited on holiday approvals. When the information and authority needed to make decisions depend on specific individuals or on weekday staffing, response can stall regardless of how big the underlying fault is.

What the five cases have in common

These five outages differ in sector and scale, but placed side by side, several common threads emerge.

1. Small triggers, such as a setting or a calculation, can have large consequences

Damai’s configuration error, Tencent Cloud’s unit conversion bug, and Kaiyuan Securities’ network failure were each local problems on their own. Whether an organization can see, in normal times, which changes and components could ripple out to which services determines how quickly it can grasp the scope of an incident.

2. The first assessment can be wrong

DeepSeek’s outage continued after being marked as resolved, Tencent Cloud’s investigation initially stopped at the billing level, and Shanghai Telecom’s first message understated the scope. Initial hypotheses being wrong is not unusual in itself. The real question may be how long it takes to realize a hypothesis is wrong, and whether there is a mechanism for sharing that realization with everyone involved.

3. Reporting and communication are part of the response, not something that comes after recovery

For Kaiyuan Securities, the delayed report was itself the reason for regulatory action, while at DeepSeek and Shanghai Telecom, users were left uneasy because no cause was given. It increasingly seems that the quality of crisis response is measured not only by speed of recovery but by the ability to keep explaining the situation as it unfolds.

4. Everyday structures can become bottlenecks in an emergency

Approvals stuck over a holiday, customer service lines that cannot be reached, and information that never travels from front-line support to developers: these problems are closely tied to knowledge silos, where decisions and information are concentrated in particular people or teams. A system that cannot make a decision without a specific person present is at its most fragile during an incident.

5. Similar failures recur within the same organization

Damai’s repeated configuration problems and Shanghai Telecom’s three wide-area outages in two years both point to the same issue. When each post-incident response ends with an apology and compensation, the organization does not carry the lessons forward. What is being tested is whether there is a mechanism that turns incident records and reviews into future prevention.

Implications for financial institutions, government, and critical infrastructure in Japan

These five cases come from China, but the underlying patterns seem to apply just as well to organizations in Japan. Financial institutions with regulatory reporting obligations, and government agencies and infrastructure operators whose services directly affect daily life, face a particular risk: as in Case 2, a delayed report can be treated as a more serious problem than the technical failure itself.

At IncidentTech, we are working on these challenges through the development of an AI agent for incident response. Our core principle is a clear division of roles: AI takes on the work that supports decisions, such as real-time visibility into what is happening, suggesting response options, and drafting incident reports, while people make the decisions that cannot be undone. Noticing quickly when an initial assessment turns out to be wrong, making sure anyone on the team can reach the same information regardless of who is on duty, and moving communication and reporting forward in parallel with the response itself: the more we study cases like these, the more important those capabilities seem.

In your organization, is it clear who starts reporting and communicating when an incident occurs, when they do it, and on what basis? We hope these cases offer a useful starting point for reviewing your own approach.

References

This article is based on official company statements and the media reports listed below. Where root causes have not been disclosed, the analysis reflects information available at the time of reporting.

Aaj News (Reuters), “China’s DeepSeek AI chatbot suffers longest outage since viral rise in early 2025,” March 30, 2026 https://english.aaj.tv/news/amp/330456120
Storyboard18, “DeepSeek chatbot faces over seven-hour outage, longest since debut,” March 30, 2026 https://www.storyboard18.com/digital/deepseek-chatbot-faces-over-seven-hour-outage-longest-since-debut-93684.htm
Implicator, “DeepSeek Chatbot Suffers Seven-Hour Outage, Longest Since Its 2025 Viral Debut,” March 30, 2026 https://www.implicator.ai/deepseek-chatbot-suffers-seven-hour-outage-longest-since-its-2025-viral-debut/
Securities Times (via Stockstar), “两家券商收罚单！一家涉网络安全迟报，一家经纪自营双双违规,” August 8, 2026 https://wap.stockstar.com/detail/IG2026080800008227
Cailian Press, “APP故障影响客户交易，开源证券接警示函，未及时上报“踩雷区”,” August 7, 2026 https://www.cls.cn/detail/2448523
IT Home, “大麦回应抢不了票：人工配置失误影响开票，故障已紧急修复,” July 20, 2026 https://www.ithome.com/0/978/953.htm
Sina Finance, ““人工配置失误”！大麦抢票故障，普通用户免费退票剩24小时，一周两度“翻车”,” July 20, 2026 https://finance.sina.cn/chanjing/gsxw/2026-07-20/detail-iniimzha9780003.d.html
Jiemian, “鹿晗演唱会售票现BUG，大麦深夜致歉：将退款退票,” June 30, 2025 https://m.jiemian.com/article/12969340.html
Jiemian, “提前放票引发不满，大麦深夜致歉：平台工作人员配置失误,” January 2026 https://m.jiemian.com/article/13841558.html
Kuai Technology (via Sina Tech), “上海电信突发大范围断网 手机信号网络全无：官方致歉 已陆续恢复,” August 31, 2026 https://finance.sina.cn/tech/2026-08-31/detail-iniqehwx4644549.d.html
Guancha, “用户一觉醒来欠费5万块、被停服17小时，腾讯云致歉,” October 7, 2026 https://www.guancha.cn/CaiJing/2026_10_07_903412.shtml
Cailian Press, “腾讯版“龙虾”一日两崩 腾讯云致歉补偿1000Credits,” April 2, 2026 https://www.cls.cn/detail/2333702