Ecommerce observability: how to prepare checkout for Black Friday 2026

The most expensive commerce incidents rarely start with a dramatic "the server is down". More often everything looks calm: CPU at 22%, memory normal, database responding, load balancer returning mostly 200s. Yet buyers see payment errors, cart disappears after refresh, discount code works one in three times or inventory API returns a state from 20 minutes ago.

On Black Friday the problem is sharper because the incident does not only consume engineering time. It burns ad spend, discount budget, customer attention and brand trust. If the team spends the first 40 minutes arguing whether the issue is frontend, MedusaJS, Stripe, ERP, Redis or database, the campaign is already funding abandoned carts.

That is why observability is not a "nice DevOps dashboard". It is the operating capability to answer: where exactly is the purchase path breaking and what can we safely disable, throttle or fix without stopping sales?

Monitoring answers known questions: is the host up, does the endpoint respond, did CPU cross a threshold, did HTTP 500s rise. You need it, but it assumes you knew in advance what was worth measuring.

Observability goes further. OpenTelemetry describes a properly instrumented application as one where the team does not need to add new telemetry to troubleshoot because the required signals already exist: traces, metrics and logs. In commerce, that means tracing one purchase attempt from the "Pay" tap through storefront, cart, pricing, inventory, payment provider, order service and ERP sync.

The practical test is simple: can you answer in five minutes what percentage of failed checkouts belongs to a specific payment method, campaign, region, app version, promotion variant or ERP integration? If not, you have monitoring, but not sales-grade observability.

Google SRE recommends watching four golden signals: latency, traffic, errors and saturation. For ecommerce, translate them into revenue language, not only infrastructure language.

The most important SLI is not "API uptime". It is the percentage of users who can complete the critical path PDP -> cart -> checkout -> payment -> order confirmation within an acceptable time. If the payment provider returns 200 but order confirmation is never created, it is still a business failure.

Example SLOs before a campaign: 99.5% of add-to-cart attempts below 800 ms on backend, 99% of payment attempts with a clear status within 10 seconds, less than 0.5% technical checkout failures and an alert when conversion-to-payment drops without a matching marketing-traffic explanation.

Distributed tracing is critical because checkout crosses many services. In headless commerce, a typical flow touches Next.js storefront, API gateway, MedusaJS or another commerce core, NestJS services, PostgreSQL, Redis, payment provider, tax/shipping, ERP/PIM/WMS and event queues.

Every request should carry a trace ID/correlation ID across services and into logs. Then the incident "payment is broken" can turn into facts: 70% of latency sits in promotion validation, 20% in payment intent, and order confirmation disappears in a subscriber after the `order.placed` event.

Medusa uses events and subscribers for actions after commerce operations, for example after an order is placed. That is a strong pattern when side effects do not block checkout, but at peak you must see queue lag, retry count, dead-letter queue and the impact of subscribers on final order confirmation.

The worst alerts say "something looks weird". Good alerts say "customers cannot buy or soon will not be able to". During peak sales, limit human-paging signals to those that affect revenue, trust or security.

Infrastructure alerts are still needed, but they should support diagnosis, not dominate the incident channel. If p95 checkout latency rises, you want the segment immediately: mobile web or app, payment method, region, campaign, coupon, API version, cache hit ratio, DB locks, queue lag and latest deployment.

Strong Black Friday alerts: technical checkout failure rate, payment authorization decline anomaly, add-to-cart drop, order-created/payment-captured mismatch, inventory stale age, coupon validation latency, ERP sync backlog, app crash-free users and API p95/p99 for critical endpoints.

Observability without runbooks ends with a team seeing the problem but not knowing who can decide. Before the campaign, define who can close a promotion, disable the recommendation widget, switch payment fallback, contact the ERP operator and decide on rollback.

Strong commerce systems have planned degradation. If recommendations fail, checkout must work. If confirmation email is queued, payment must not wait. If ERP sync is delayed, the user should receive clear order status and operations should see the backlog.

A runbook should contain entry threshold, owner, first 5 minutes of diagnosis, links to dashboards/traces, safe switches, support message and exit criteria. Without that, incident response depends on the memory of people under maximum pressure.

A load test that only measures homepage and PDP creates false confidence. The critical test is cart -> delivery -> payment -> order confirmation -> side effects. Also test coupons, inventory limits, logged-in/guest checkout, payment retries and return from gateway.

Before peak, run a game day: deliberately slow a payment provider, disable an ERP sandbox endpoint, increase queue lag, raise database latency or simulate a promotion bug. The team should see the alert, find the trace, run the runbook and decide on degradation.

The point is not to perfectly simulate Black Friday. The point is to check whether the team can quickly distinguish critical from secondary failure, whether dashboards show business impact and whether decision owners know what they can disable without settlement risk.

In GMI commerce projects we often combine Next.js storefront, React Native/Expo for apps, MedusaJS or custom commerce core, NestJS for domains and integrations, PostgreSQL, Redis, queues and ERP/PIM/WMS. We design observability as part of architecture, not as a tool bolted on after launch.

During DDT we map critical flows, systems of truth, integration risks and business metrics. Only then do we decide where traces are needed, which logs require correlation IDs, which events run asynchronously, which alerts page humans and what the client owns after delivery: source code, dashboards, runbooks, API contracts and maintenance backlog.

This is also where cost becomes realistic. Fixed price after DDT only makes sense once we know which parts of the system must survive peak, which can degrade and which require a narrow specialist for performance, security, database or payments.

Use this list at least 4-6 weeks before Black Friday, a major campaign or a new mobile commerce channel launch. If the answers are unclear, you are not peak-ready; you only hope the system will survive.

• Do we have SLIs/SLOs for PDP, add-to-cart, checkout, payment, order confirmation and app crash-free users?
• Does every critical request carry trace ID/correlation ID from frontend/app to backend, payments and integrations?
• Do business alerts show purchase drop, payment/order mismatch, queue lag and stale inventory?
• Do runbooks have owners, entry thresholds, dashboard links, degradation decisions and support messages?
• Did we test the full purchase path, not only homepage and catalogue?
• Can feature flags disable promotions, recommendations, newsletter popup or heavy integrations without stopping checkout?
• Do we know the rollback plan, code freeze, on-call schedule, incident channel and exit criteria?