Why promo codes break during Black Week
In 2026, Black Friday falls on 27 November and Cyber Monday on 30 November. From the publication of this article that is a little over five weeks, and many shops are planning their promotions now. Demand is high: in a Bitkom survey, roughly one in two respondents (52 %) wanted to use the reduced prices around Black Friday 2025, most of them online (Bitkom). Of those interested, 69 % planned to look for deals exclusively online (Bitkom).
Discounts are also a criterion for choosing a shop: 47 % of online shoppers rate price and discounts as very important when selecting an online shop (Bitkom). The survey covered 1,120 internet users aged 16 and over, including 1,072 online shoppers (Bitkom). An advertised code therefore creates a concrete expectation, and if it fails in the cart, that expectation breaks exactly where the purchase is almost decided.
The pattern is usually the same: promotions are created shortly before the deadline, often by marketing, and start on a day when the shop team is busy with load and shipping. Uptime monitoring reports a reachable homepage, a standard checkout test runs without a code, and neither of them tests redemption. Why a green uptime check says little about the purchase flow is explained in Browser monitoring: when uptime is green but checkout is broken.
The Bitkom figures come from a representative survey in calendar weeks 40 and 41 of 2025, and the Baymard Institute figures come from its benchmark article of June 2024. None of the sources measures how often discount codes are misconfigured; the failure patterns in this article therefore come from the documentation of the shop systems.
Where redemption typically fails
Shop systems differ in their terms, hardly in their settings. In Shopware 6 you define whether a promotion is time-limited, how often it may be used in total and per customer, and whether it is active; a deactivated promotion is not applied even within its validity period (Shopware documentation). In WooCommerce the same settings are called expiry date, usage restrictions and usage limits (WooCommerce documentation).
- Period: Start too late, end too early. In WooCommerce a coupon can no longer be used on the expiry date that has been set (WooCommerce documentation); entering 30 November there loses Cyber Monday.
- Minimum value: The threshold refers to a different total than intended. Shopware distinguishes between the total and the subtotal of all items, which only takes the value of the products into account, not shipping or other discounts (Shopware documentation). WooCommerce uses the displayed cart subtotal, including tax when the cart shows gross prices (WooCommerce documentation).
- Exclusions: If the product rule for excluded items is set as a cart condition instead of on the discount, the promotion can no longer be triggered as soon as a single excluded item is in the cart (Shopware documentation). In WooCommerce a separate option excludes sale items from the discount (WooCommerce documentation); anyone who already marks items down for Black Week thereby excludes them from the code.
- Customer group: Customer rules determine who may benefit from a promotion (Shopware documentation), and WooCommerce checks an email restriction against the billing email (WooCommerce documentation). Customers are open to this: 56 % of online shoppers are willing to share their data for discounts (Bitkom).
- Combination: If combination is blocked for a promotion, no other promotion can be used in the same cart, even if its conditions would be met (Shopware documentation). If an automatic promotion without a code has this lock and applies first, the advertised code can end up having no effect.
- Regenerated codes: Adjusting and regenerating individual codes afterwards makes the previous codes invalid (Shopware documentation), including those already sent.
Corrections during the promotion are also limited. Once a promotion has been used in an order for the first time, its discount settings can no longer be changed in Shopware (Shopware documentation). A discount error that only shows up on the promotion day then needs a new promotion and possibly a new code. The table maps the failure patterns to the findings of the browser check.
| Setting | Typical error | What the browser check sees |
|---|---|---|
| Valid from and until | End one day too early, start after the newsletter | Discount line missing, message about the period |
| Active switch | Promotion created but not activated | Code is rejected |
| Minimum value | Gross instead of net, subtotal instead of total | Discount only with a larger cart |
| Exclusions | Exception rule set as a cart condition | No discount once an excluded item is in the cart |
| Customer group | Existing customers only or wrong group | Test customer gets no discount |
| Regenerated codes | Codes already sent become invalid | Known code is rejected |
State the conditions clearly: what Section 6 DDG requires
Besides the technology there is a legal side. Under Germany's Digital Services Act (DDG), sales promotion offers such as price reductions in online commercial communications must be clearly recognisable as such, and the conditions for using them must be easily accessible and stated clearly and unambiguously (Section 6 DDG). For a discount code this means: minimum order value, period, excluded items and customer group restrictions must be easy to find from wherever the code is advertised, and they should match what is actually configured in the shop.
Sales promotion offers such as price reductions, add-ons and gifts must be clearly recognisable as such, and the conditions for taking advantage of them must be easily accessible and stated clearly and unambiguously.
— Section 6(1) no. 3 Digital Services Act (DDG), unofficial translation
This is where a browser check helps. The banner names a minimum order value while the shop rule calculates with a different total; the newsletter promises a discount on everything while the promotion excludes sale items. A check that works with the advertised conditions, that is, with a cart just above the advertised minimum value and an item from the advertised category, reveals the discrepancy before customers notice it.
The provisions of the German Act against Unfair Competition and the Price Indication Ordinance remain unaffected (Section 6 DDG); what applies to strikethrough prices is covered in the article on strikethrough prices on Black Friday. This section is not legal advice.
Redemption as a browser check
In XICTRAQ® browser monitoring, a real Chromium browser drives a multi-step flow (XICTRAQ® documentation): open a page, click, fill in fields, wait for elements, check text or the address. A scenario can have up to 40 steps, and the interval ranges from 5 minutes to 24 hours (XICTRAQ® documentation). Redeeming a code needs only a fraction of that.
Where the code field sits depends on the shop. In the Baymard Institute's e-commerce benchmark, 70 % of sites have a field for promo, discount or coupon codes (Baymard Institute). The institute recommends hiding the field behind a link because some test participants left the checkout to search for codes; 35 % of sites with such a field still display it by default (Baymard Institute). If the field is collapsed, the check needs a click on that link first. In Shopware, the code can be entered in the off-canvas cart and in the regular cart view, after which the discount appears in the item overview (Shopware documentation).
The scenario shows the flow for a test code bound to the test customer. Addresses and selectors are placeholders; the real ones are in your own shop's template.
{
"name": "Promo code BLACKWEEK-TEST, stop before the order",
"viewport": { "width": 1280, "height": 800 },
"timeout_ms": 20000,
"step_retry": 1,
"steps": [
{ "type": "goto", "url": "https://shop.example.invalid/account/login" },
{ "type": "fill", "selector": "#login-email", "value": "monitoring@shop.example.invalid" },
{ "type": "fill", "selector": "#login-password", "value": "***" },
{ "type": "click", "selector": "form.login-form button[type=submit]" },
{ "type": "wait_for", "selector": ".account-welcome" },
{ "type": "goto", "url": "https://shop.example.invalid/promo/test-product" },
{ "type": "click", "selector": ".buy-widget button[type=submit]" },
{ "type": "goto", "url": "https://shop.example.invalid/checkout/cart" },
{ "type": "click", "selector": ".promo-toggle" },
{ "type": "fill", "selector": "#promo-code", "value": "BLACKWEEK-TEST" },
{ "type": "click", "selector": "#promo-apply" },
{ "type": "wait_for", "selector": ".cart-line-discount", "timeout_ms": 10000 },
{ "type": "assert_text", "selector": ".cart-line-discount", "contains": "Discount" },
{ "type": "screenshot", "full_page": true }
]
}Three details matter. First, assert_text checks the text of the discount line, not just its existence: the selector's text must contain a substring or match exactly, and for contains the comparison is case-sensitive (XICTRAQ® documentation). Second, for code fields that react to every keystroke, the type step helps instead of fill because it types character by character (XICTRAQ® documentation). Third, the flow ends with a screenshot, not with the order button.
To handle flakiness, each step can set a retry count from 0 to 3 (XICTRAQ® documentation). A step may take at most 60 seconds, and the whole run is aborted after 90 seconds (XICTRAQ® documentation). If you prefer to record the flow, the article Record browser flows and monitor them automatically shows the route via the Chrome Recorder; all step types are listed in the browser monitoring documentation.
Test code and test customer: no real orders
A check that tests discount codes should not leave traces in revenue or promotion statistics itself. The Shopware monitoring page therefore recommends letting browser checks end on the order review page and using a dedicated test customer (XICTRAQ®). Up to that point the check covers almost the entire purchase path: in the Baymard Institute's benchmark (as of 2024), checkout for new customers averages 5.1 steps, counted from the cart up to and including the order review (Baymard Institute).
For the code itself there are two complementary variants:
- Permanent test code: a separate promotion with the same structure as the real one, released only for the test customer group via a customer rule. XICTRAQ® stores the scenario's field values encrypted, but production logins should still use a dedicated monitoring account with minimal privileges (XICTRAQ® documentation).
- The real promo code: At the start time and in the first hours, a second monitor checks exactly the code from the newsletter, with the same test customer in the matching customer group and again stopping before the order.
In Shopware, individual codes can only be redeemed once and are not accepted when entered again (Shopware documentation). If you send them, reserve one for the check. Because the check stops before the order, the code is usually not booked as redeemed; whether this holds with all extensions is shown by the list of redeemed codes after the first runs.
A click on “Place order” in the live shop creates a real order on every run, counts against the promotion's usage limits and ends up in revenue, inventory management and shipping. The flow therefore ends in the cart or on the order review page; completion with payment is tested in a test environment.
Your own analytics stay clean as well: the runner blocks the XICTRAQ® tracker so that synthetic runs create no test page views, and it sends a dedicated user agent (XICTRAQ® documentation).
Test from the start time: run now and interval
The most delicate phase of a promotion is its first few minutes. If it starts at midnight and the newsletter goes out in the morning, the check should have run green several times by then. “Run now” marks a monitor as due, and the next cron tick, which runs every minute, executes it without waiting for the interval (XICTRAQ® documentation). For promotion week, this sequence works well:
- One week before: Create a test promotion with the rules of the real one, set up the positive run and the counter-check, and start both once with “Run now”.
- The day before: Test the real code in the counter-check; before the start time it must be rejected.
- At the start time: Trigger the positive run for the real code and wait for the result before the newsletter and banners go live.
- During the promotion: A tight interval and the alert routed to the person allowed to change the promotion in the shop admin.
- After the end: Counter-check with the real code. A code that still grants a discount afterwards costs margin.
WooCommerce recommends the same double test. Before sharing the code, eligible products should be added to the storefront cart and the code applied (WooCommerce documentation). A cart outside the restrictions should also confirm that the code is rejected there (WooCommerce documentation). The browser check turns this one-off manual test into a recurring one.
A deploy to the theme or a plugin can also move the code field, button or discount line without any page going down. A “Run now” after every release usually shows this within minutes; how this fits with a rollback is described in the article on deploys as a cause of outages.
Two runs per promotion: positive run and counter-check
A check that only knows the success case misses settings that are too generous. Every promotion therefore needs two monitors: the positive run expects the discount line when all conditions are met, the counter-check deliberately misses one condition and expects the shop's message. WooCommerce displays a message explaining why when a coupon cannot be applied (WooCommerce documentation); assert_text checks this text.
Eligible cart, test customer signed in, code entered. Expected: the discount line with the promotion name and a lower total.
Cart just below the minimum value or with an excluded item. Expected: the shop's message and no discount line.
A second positive run with a narrow viewport. 73 % use a smartphone for online shopping (Bitkom), and there the code field is often collapsed.
Counter-check with the real code: it must be rejected. Then pause both monitors or switch them to the next promotion.
Both runs use the conditions from the advertising. If the positive run tests with a cart far above the threshold, a wrongly set minimum value stays invisible; the telling cart is just above it, with the counter-check just below. Shops with gross and net views test both separately.
A code can be accepted and still achieve little, for example if the discount applies only to some of the items. The check therefore looks at the line that shows the deduction, not at the success message: the message says that the shop knows the code, the discount line says that the customer gets something out of it.
When the check turns red: screenshot, alert, cause
If a step fails, a failure screenshot is captured automatically at the moment of failure (XICTRAQ® documentation), along with the index of the failed step and the error message (XICTRAQ® documentation). For discount codes the image is often half the diagnosis because it shows the shop's message next to the code field.
The failure creates an alert of type browser_monitor_failed with severity critical (XICTRAQ® documentation). Deduplication (ten minutes by default), the acknowledgement link, escalation and postmortem export work as with the uptime alert (XICTRAQ® documentation), and once the run turns green again, XICTRAQ® closes the alert automatically. Delivery uses the channels of the alerting and notifications, such as email, Slack, Teams or webhook, preferably to the person allowed to change promotions in the shop admin.
The overview shows the latest 50 runs per monitor (XICTRAQ® documentation), so you can see since when a code has been rejected. The message in the screenshot usually leads straight to the first check:
- No discount line, no message: The click on “Apply” had no effect, often because of a script error or an overlaying element. How such dead click targets show up in real visits is covered in the article on rage and dead clicks.
- Message about the minimum value: Compare threshold and reference total with the advertising, gross or net, with or without shipping.
- Message about the period: Check start, end, active switch and sales channel of the promotion.
- Code unknown: Regenerated codes, a typo or a different spelling. In WooCommerce, the upper and lower case of the code does not matter (WooCommerce documentation); elsewhere the check should use the spelling from the advertising.
- Discount too small: An exception rule or a discount on only some items; check the product rules on the discount.
Finding redemptions in the sales data
The browser check tells you whether the code works, the sales data show whether it is used. The xictraq.revenue function accepts an optional object with tax, shipping and coupon code for this purpose (XICTRAQ® documentation). If you pass the code at purchase completion this way, i.e. xictraq.revenue(amount, "EUR", orderNumber, { coupon }), the e-commerce section of the cookieless analytics shows a coupon table with redemptions and revenue. The automatic shop detection does not pass the code; the parameters are described in the JavaScript tracker documentation.
If a code shows no redemptions hours after the newsletter while the check is green, the problem more likely lies with the delivery or display of the newsletter. If it is redeemed far more often than planned, the rule may be too broad. How to reconcile orders with tracked purchases is shown in the article on reconciling shop orders, and an alert for missing orders in the article on the order heartbeat.
Browser monitoring and the e-commerce analysis are included from the Business plan upwards; details are on the pricing page. Multiple monitors per website are supported, typically separate ones for login, checkout and contact form (XICTRAQ® documentation).
Checklist for every discount promotion
- Write down the conditions: period with time of day, minimum value with reference total, exclusions, customer group, usage limits, combination
- Compare newsletters, banners and ads with these conditions
- Create a test customer with a separate customer group and minimal privileges
- Set up a positive run with a cart just above the advertised threshold
- Set up a counter-check below the threshold or with an excluded item
- Add a second positive run with a narrow viewport for the mobile view
- Use “Run now” at the start time and set a tight interval during the promotion
- Route the alert to the person allowed to change the promotion in the shop admin
- After the end, run the counter-check with the real code, then pause the monitors
Check the code before your customers do
A discount promotion is a promise with conditions, and whether it reaches the cart depends on a few settings made under time pressure. A browser check that follows the path from product to discount line turns this into a measurement with a timestamp, a screenshot and an alert. Set it up a week before Black Friday and you will have a series of green runs by 27 November, and you will learn about a change made the evening before from the alert rather than from customer support.
Login and checkout behind it are covered in Monitor the login flow, and the withdrawal path as the season's second mandatory route in the article on the withdrawal button in the Christmas season.
This article is based on: Bitkom, press release “Black Friday: Die Hälfte geht auf Schnäppchenjagd” of 24 November 2025, representative survey of 1,120 internet users aged 16 and over in calendar weeks 40 and 41 of 2025; Baymard Institute, “Checkout Optimization: 5 Ways to Minimize Form Fields in Checkout” of June 2024; Shopware documentation, “Promotions”, version for Shopware 6.7.0.0 and newer; WooCommerce documentation, “Managing Coupons in WooCommerce”; Section 6 of the German Digital Services Act (DDG) on gesetze-im-internet.de; XICTRAQ® documentation on browser monitoring and the JavaScript tracker. All sources were accessed in October 2026. This article is not legal advice.