Is your checkout ready for Black Friday? The 10-minute pre-sale check
Black Friday does not create new failures; it multiplies the ones you already have and hides them behind traffic. Ten minutes of checking this week is cheaper than discovering a broken payment step on the busiest morning of the year.
The 10-minute check
Run this once this week and once the day before the sale. 1. Open a sale product as a guest: price, discount, stock. 2. Add it and confirm the cart shows the discounted price, not the old one. 3. Checkout with a real address in your main shipping zone: shipping methods appear and the cheapest is selectable. 4. Totals add up: subtotal, discount, shipping, tax. 5. The payment method loads and accepts a test payment: 6. Place a real low-value order, confirm it in the admin, confirm the email. 7. Repeat on a phone, throttling the connection if you can.
If any step fails, fix it before the sale, not during it. A discount that stacks wrongly in the cart is the classic Black Friday bug: the product page shows the sale price and the cart charges full price, or the coupon applies twice. The pattern shows up in our failure data as price mismatches between the product page and the cart.
What actually breaks under sale traffic
Our own failure data says the most common checkout problems are product and checkout-form errors rather than payment gateways, and that a third of incidents start between 22:00 and 03:00 — the deploy and cron window. On a sale night the same failures arrive with more traffic: PHP workers, Redis sessions, cache rules that only bite under load, and third-party scripts that slow the payment page.
The pattern to remember: the store answers, the homepage loads, and the order does not go through. That is exactly the failure an uptime check misses.
Load: the checks that only fail when busy
WooCommerce: watch PHP workers and the object cache. Magento: watch Redis sessions and full-page cache. Both: watch the payment provider status page and your own error rate. If you cannot run a load test, at least remove the known traps — a debug mode left on, a third-party script added last week, a cron job scheduled for midnight on the sale night.
More: WooCommerce under load, Redis on Magento, third-party scripts on the checkout.
Keep watching during the sale
The day of the sale is the worst time to discover a broken step by hand. A scheduled check every 5 to 15 minutes catches a failure inside one cycle and names the step; a status page or uptime ping will stay green through most of them. If the store is the revenue, that cadence is worth paying for.
MageSentinel checks every 5 minutes on Scale, 15 on Agency and 30 on Solo and Starter, with test orders on the plans that include them — a real order confirmed in the admin and cancelled, so the whole path is proven, not just the page.
After the sale
Turn off the sale rules, rotate the test product and keep the check. The failures do not stop on Monday; they get quieter. Review what fired during the sale and delete the alerts nobody acted on — alert fatigue is the real risk after a busy weekend.
Find out your checkout broke before your customers do.
Real checkout checks for Magento and WooCommerce · 14 days free · no card requiredCommon questions
How early should I check the checkout before Black Friday?
A week before for fixes, and again the day before the sale. Discounts, shipping zones and payment methods are the three things that change most in between.
What is the most common Black Friday checkout failure?
A cart that does not honour the sale price, followed by shipping methods that disappear for some countries and payment forms that fail on phones.
Do I need monitoring during the sale?
If a broken checkout costs you orders, yes: a check every 5 to 15 minutes finds the failure inside one cycle instead of after a customer complains.