What really broke ChatGPT on March 20

Imagine opening ChatGPT to continue your work, only to find another user's chat titles in your sidebar—and someone else's billing address under your account settings. Earlier this week, that nightmare briefly became reality.

OpenAI published an exhaustive post-mortem explaining the March 20 outage that took ChatGPT offline, confirming that a software glitch exposed conversation history snippets and payment data.

The company revealed that a bug in an open-source library allowed some active users to view titles from other active users' chat histories. If two people were active at roughly the same time, the first message of a newly created conversation was also potentially visible.

A nine-hour window and 1.2% of Plus subscribers

The issue went beyond chat logs. A deeper investigation revealed that payment-related information of roughly 1.2% of active ChatGPT Plus subscribers was unintentionally exposed during a specific nine-hour window on Monday, March 20, between 1 a.m. and 10 a.m. Pacific time.

During that period, affected users might have had their first and last name, email address, payment address, credit card expiration date, card brand, and the last four digits of their card number exposed to another active user. OpenAI emphasized that full credit card numbers were never exposed at any point.

Actual exposure required precise actions. A subscriber had to either open a subscription confirmation email sent to the wrong recipient during that nine-hour span, or click into Manage my subscription inside the account settings at just the right time.

OpenAI confirmed it has reached out to notify all affected users and stated there is no ongoing risk to data security.

How an async connection pool misbehaved

The root cause was not an AI failure or an external breach, but a tricky bug in redis-py, the open-source Python client library used to talk to Redis Cluster.

OpenAI uses Redis to cache user information and reduce database load, running Asyncio on its Python servers with a shared connection pool.

When a request was canceled after being pushed to the incoming queue but before the response was retrieved from the outgoing queue, the connection became corrupted. An unrelated subsequent request using that recycled connection ended up receiving the leftover response.

To make matters worse, a server change deployed at 1 a.m. Pacific time on March 20 caused a sharp spike in canceled Redis requests, drastically increasing the chances of bad data being served.

OpenAI worked directly with Redis maintainers to patch the library, while adding redundant checks in its own infrastructure to verify that cached data strictly matches the requesting user.

Why it matters

We think this incident is a critical wake-up call for the entire AI sector. While researchers and regulators obsess over existential risks, prompt injections, and jailbreaks, this breach came from standard, old-school software engineering plumbing.

For users and enterprises pouring proprietary code, financial summaries, and sensitive drafts into AI interfaces, privacy is the entire ballgame. Seeing another stranger's prompt title or billing receipt destroys trust instantly, regardless of whether full card numbers leaked.

OpenAI deserves credit for a transparent, highly detailed technical post-mortem and for contributing fixes directly back to open-source maintainers. However, it also proves that rapid scaling under unprecedented traffic creates massive operational strain.

As AI providers race to attract corporate subscriptions, winning will require far more than benchmark scores. Boring, bulletproof infrastructure hygiene and strict tenant isolation will decide who actually gets enterprise budgets.