Shopify's Cyber Monday 2025 outage: what a shared auth chokepoint looks like under peak merchant load

December 1, 2025 was Cyber Monday, the peak day of Shopify’s biggest BFCM weekend on record. The platform processed a record $14.6 billion in GMV across the Black Friday–Cyber Monday weekend. For roughly five to six hours of that day, merchant admins, point-of-sale systems, API integrations, and login flows were down.

Shopify’s storefront checkout, the path a shopper takes to buy something, largely survived. The layer that failed is the one merchants use to run their stores: the admin dashboard, POS terminals, API tokens, and the login flow that ties them together. Shopify officially attributed the disruption to a problem with its login authentication flow.

What happened

On December 1, 2025, starting roughly at the morning peak around 11:00 a.m. ET, Shopify merchants began reporting that they could not reach their admin dashboards or POS terminals. API integrations that used token-based authentication failed too. The disruption lasted about five to six hours, according to TechCrunch and CNBC.

Shopify resolved the issue and publicly stated the outage was caused by a problem with its login authentication flow. It released no further technical postmortem. The company did not say whether load, a deployment, or a configuration change caused the authentication issue, so public reporting does not establish the specific technical root cause.

Two things are confirmed. The outage hit on the highest-concurrency merchant day of the year, and the component that failed was the authentication layer shared by admin, POS, and API access.

The timeline

• Morning, December 1, 2025 (~11:00 a.m. ET): Merchant reports of admin and POS failures begin climbing; API authentication failures follow.
• ~5–6 hours of disruption: TechCrunch and CNBC report the outage duration; storefront checkout mostly available throughout.
• Shopify statement: The company officially attributed the cause to a login authentication flow issue.
• Resolution: Service restored; merchants regained admin and POS access.
• Context: The record $14.6B BFCM GMV weekend confirms this was peak concurrent-merchant demand.

Why it happened

Shopify has not published a detailed postmortem, so nobody outside can confirm the specific technical cause. The reporting does establish that the authentication flow failed on the highest-concurrency day of the year, and that it was the component shared by several merchant-facing surfaces (admin, POS, API).

A shared authentication path, a concentrated concurrency peak, and no official RCA together match a well-understood pattern in distributed systems. When many sessions need to authenticate or re-authenticate at about the same time (Cyber Monday morning, when merchants open their dashboards and start their POS terminals), a shared auth service faces a thundering herd. If that service has a capacity ceiling, whether in its own infrastructure, an upstream token-verification store, or a downstream session database, a simultaneous surge can exhaust it faster than the system can recover or scale.

Storefront checkout, which serves shoppers buying products, largely survived. That supports the inference that the failure was specific to the authenticated-session layer and not to Shopify’s infrastructure as a whole.

The failure pattern

This is a thundering herd aimed at a shared authentication chokepoint. Its defining trait: many clients need the same shared resource at the same time, and that resource is a stateful, write-heavy path (session creation, token verification) that caching cannot help the way it helps read-only content.

The pattern shows up in many kinds of systems. Every merchant opens the admin at 9:00 a.m. Every user tries to log in when a service returns from maintenance. Every mobile app re-establishes a session after a push notification. It differs from a general traffic spike because the bottleneck is almost always the write path for authentication state, and that path is usually one shared system.

The general point for any platform team: a shared authentication layer is your most likely single point of failure during a simultaneous-login event, and it is the path least likely to have been load-tested at realistic concurrent scale.

How it could have been prevented

Test the auth path on its own, alongside the storefront. Most load testing effort goes to product pages, search, and checkout. The login and session-creation flow needs write operations, token issuance, and often external calls to an identity provider, and it is often undertested. Give it dedicated load scenarios at peak concurrency.

Find the breakpoint before the event. A breakpoint test on the auth endpoint tells you how many concurrent sessions your system can admit before error rates climb. Run it weeks before BFCM and you have a number to size against.

Decouple admin auth from storefront checkout. If merchant admin sessions share infrastructure with the checkout payment path, a surge in admin logins can degrade checkout. Plan capacity separately for merchant-facing and consumer-facing authentication to shrink the blast radius.

Use admission control and graceful degradation. When an auth system nears saturation, reject new sessions with a clear error (503 with a retry header) instead of timing out silently or returning inconsistent results. Rate limiting at the auth layer gives the system time to drain.

Pre-warm sessions before peak windows. For predictable events like Cyber Monday, ask merchants to log in the evening before, when concurrency is low. That shrinks the session-creation spike the next morning.

How to test for this with MaxoPerf

Shopify’s pattern calls for two complementary runs against your own authentication and admin-session endpoints: a spike test that models the simultaneous-login event and a breakpoint test that finds the exact concurrency ceiling.

Engine: k6 or Taurus (JMeter)

Profile, spike: a closed-model spike on your auth/login endpoint. Start at a low baseline concurrency and jump to your expected peak merchant or admin login concurrency in under 60 seconds. Size the peak from historical data or from a worst-case estimate based on your active user count. Hold for 10–15 minutes. This models the “everyone opens their dashboard at 9 a.m.” scenario.

Profile, breakpoint: step the load in increments (e.g., every 2–3 minutes, increase concurrent sessions by 10–20%) until p99 latency exceeds your p95 and p99 latency thresholds or the error rate climbs above your tolerance. The point where the curve breaks is your current capacity ceiling. Record it. You now have a number to plan against and a baseline for future runs.

Target: your own staging or pre-production auth environment, specifically the login, token-issuance, and session-creation path. Run it apart from the read-heavy storefront paths so you can isolate auth-layer behavior. If your platform uses an identity or session service, target that service’s endpoints directly as well.

Locations: run from at least two managed cloud regions at once to model merchants in different geographies logging in at the same moment. If your auth service is reachable only from internal infrastructure, use a private/BYOC location.

What to watch in results:

• p95 and p99 latency on the login and token-issuance labels. Look for the knee where latency bends sharply as concurrency climbs.
• Error rate on the auth endpoint. The first sustained rise above zero tells you when the system starts rejecting or timing out sessions.
• Throughput (sessions admitted per second). If it plateaus while concurrency climbs, you have found the ceiling.
• Run artifacts and logs for downstream errors from session stores, token-verification databases, or identity provider calls. They show which layer is saturating.

Failure criteria: set thresholds before the run. For example, p99 login latency must not exceed your agreed limit, and the error rate must stay below your tolerance. The breakpoint run gives you the concurrency above which those criteria fail, and that number becomes your planning input for BFCM capacity.

Schedule the spike and breakpoint runs at least six to eight weeks before Cyber Monday. Size your capacity target from the breakpoint result, then rerun the spike test after any change to confirm the ceiling moved the right way.

To build performance checks into your release pipeline before peak season, see the CI/CD performance gates pattern. A pre-release spike on the auth path catches auth-layer regressions before they reach production.

Key takeaways

• Shopify officially attributed the Cyber Monday 2025 outage to a login authentication flow issue. It released no further public RCA, so reporting does not confirm the specific technical cause.
• A thundering herd at an auth chokepoint, with many simultaneous sessions hitting a shared write path, is one of the most common failure modes on peak commercial days.
• Storefront reads can survive an auth outage because they are often cached or served independently. Test your auth path as its own first-class concern.
• A breakpoint test on your auth endpoint gives you a concrete concurrency ceiling to plan against, instead of a feeling that things “should be fine.”
• p95 and p99 latency on the login flow are the key signals. Rising tail latency is an early warning that the auth system is nearing saturation.

Want to find your auth endpoint’s concurrency ceiling before BFCM? Run a breakpoint test on MaxoPerf: define the load shape, point it at your own login endpoint, and read the knee in your results.