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

December 1, 2025 — Cyber Monday — was 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. And 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. What failed was the layer that merchants themselves use to manage 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 they could not access their admin dashboards or POS terminals. API integrations using token-based authentication also failed. The disruption lasted approximately five to six hours according to TechCrunch and CNBC reporting.

Shopify resolved the issue and publicly stated the outage was caused by a problem with its login authentication flow. No further technical postmortem was released. The company did not confirm whether the authentication issue was caused by load, a deployment, or a configuration change — so the specific technical root cause remains outside what public reporting supports.

What is confirmed: the outage hit on the highest-concurrency merchant day of the year, and the component that failed was the authentication layer shared across 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: Record $14.6B BFCM GMV weekend confirms this was peak concurrent-merchant demand.

Why it happened

Without a detailed postmortem from Shopify, the specific technical cause cannot be confirmed. What the available reporting establishes is that the authentication flow failed on the highest-concurrency day of the year, and it was the shared component across multiple merchant-facing surfaces (admin, POS, API).

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

The fact that the storefront checkout path (serving end-consumers buying products) largely survived supports the inference that the failure was specific to the authenticated-session layer rather than Shopify’s infrastructure broadly.

The failure pattern

This is a thundering-herd concentrated at a shared authentication chokepoint. The defining characteristic: many clients all needing the same shared resource at the same time, with the resource being a stateful, write-heavy path (session creation, token verification) that does not benefit from caching the way read-only content does.

This pattern appears across many system types: every merchant opening their admin at 9:00 a.m., every user trying to log in when a service comes back after maintenance, every mobile app re-establishing a session after a push notification. What distinguishes it from a general traffic spike is that the bottleneck is almost always the write path for authentication state — and that path is usually a single shared system.

The generalization for any platform team: if you have a shared authentication layer, it 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 specifically, not just the storefront. Most load testing effort goes to product pages, search, and checkout. The login and session-creation flow — which requires write operations, token issuance, and often external calls to an identity provider — is frequently undertested. It needs its own dedicated load scenarios at peak concurrency.

Find the breakpoint before the event. A breakpoint test on the auth endpoint tells you the maximum concurrent sessions your system can admit before error rates climb. Running this weeks before BFCM gives you an actionable 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. Separate capacity planning for merchant-facing and consumer-facing authentication reduces blast radius.

Use admission control and graceful degradation. When an auth system approaches saturation, rejecting new sessions with a clear error (503 with a retry header) is better than silently timing out 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, prompting merchants to log in the evening before — when concurrency is low — reduces the simultaneous session-creation spike the following morning.

How to test for this with MaxoPerf

Shopify’s pattern calls for two complementary test runs targeting your own authentication and admin-session endpoints: a spike test to model the simultaneous-login event and a breakpoint test to find the exact concurrency ceiling.

Engine: k6 or Taurus (JMeter)

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

Profile — breakpoint: step 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 error rate climbs above your tolerance. The point where the curve breaks is your current capacity ceiling. Record it. Then you have a number to plan against and a baseline to compare future runs against.

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

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

What to watch in results:

• p95 and p99 latency on the login and token-issuance labels — watch for the knee where latency inflects 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 this plateaus while concurrency climbs, you’ve found the ceiling.
• Run artifacts and logs for downstream errors from session stores, token-verification databases, or identity provider calls — these identify which layer is actually saturating.

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

Schedule the spike and breakpoint runs at least six to eight weeks before Cyber Monday. Use the breakpoint result to size your capacity target, then re-run the spike test after any changes to confirm the ceiling moved in the right direction.

For building performance checks into your release pipeline ahead of 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; no further public RCA was released, so specific technical causes are outside what reporting confirms.
• The thundering-herd pattern at an auth chokepoint — many simultaneous sessions hitting a shared write path — is one of the most common failure modes on peak commercial days.
• Storefront reads can survive when auth goes down because they are often cached or independently served; test your auth path as a separate, first-class concern.
• A breakpoint test on your auth endpoint gives you a concrete concurrency ceiling to plan against, not just 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 approaching 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.