Sale app not working on Black Friday? What keeps running

“Shopify sale app not working black friday” is a search nobody wants to be making at 7 a.m. on the busiest day of the year. Whether that search ends in a shrug or a disaster depends on a question most merchants never ask before installing: when the app’s servers are unreachable, which parts of your sale keep working? This article explains the two ways a sale app can run a promotion, why one of them keeps discounting while the app is down and the other does not, how long a bulk discount really takes to apply, and what SafeSale does and does not promise.

The problem: the sale depends on someone else’s server

Reliability complaints cluster in the low-star reviews of every long-lived bulk-discount app. On Bold Discounts’ review page a November 27, 2020 review describes waking up on the day of a BFCM launch to “dozens of emails and DMs from frustrated customers” whose discount vanished in the cart; an August 13, 2020 review asks “seriously how long does it take to get this app back up”; a September 3, 2021 review says that every time the merchant turned a sale on or off they “had to wait like 30 mins for it to complete”. On Amai Bulk Discount’s review page a March 13, 2019 review reports being told it “would take up to 24 hours to clear the wrong rule”, and a November 9, 2024 review (in Spanish) describes a discount taking up to a day to activate. As always, read the pages, including the developers’ replies, rather than our excerpts.

None of these are about the discount maths. They are about latency and availability: how long a change takes to reach the storefront, and what happens while it is in flight.

Why it happens: two very different architectures

Automatic discounts run inside Shopify

Shopify’s automatic discounts are applied by Shopify in the cart and at checkout whenever the conditions are met; there is no per-product write and nothing for a shopper to enter. Apps can create them too. An app-created automatic discount is backed by a Shopify Function, a small program that Shopify itself executes. The Functions documentation is explicit: functions “are never invoked directly by URL or otherwise. Shopify invokes them as-needed within the customer journey.” The Discount Function API runs that logic inside the checkout flow, and the discount’s start and end times are fields on the discount object that Shopify enforces.

The consequence for reliability: once the app has created the discount, the app’s server is not in the path between your shopper and the price they pay. If the vendor’s hosting falls over mid-morning, the cart still shows the discount, checkout still applies it, and it still switches off at the end time. What you lose while the app is down is the ability to change the sale: editing, ending early, or starting a new one.

Price rewrites run through the app, one product at a time

The other mechanism, rewriting each variant’s price and compare-at (see automatic discount versus compare-at rewrite), is a batch job on the app’s side. The Admin API mutation that updates variant prices, productVariantsBulkUpdate, works on “multiple product variants for a single product in one operation”, so a sale across 1,500 products is at least 1,500 API calls. Each call spends points from a per-store budget described in the GraphQL Admin API rate limits, with a restore rate that depends on your Shopify plan. That is the physics behind “how long does a bulk discount take to apply”: it scales with catalog size and is bounded by Shopify, not by how fast the app’s servers are.

It also explains what a mid-run outage looks like. If the app dies with 600 of 1,500 products written, the storefront is a mix of sale and full prices, and it stays that way until the app is back to finish or undo the job. If the app is still down at the end time, the sale does not end. A shared queue that is also serving thousands of other stores on the same morning is how “wait 30 minutes” and “up to 24 hours” happen.

Storefront scripts add a third failure mode

Apps that show discounted prices by injecting JavaScript into the theme depend on that script loading and on it not fighting with other scripts. The November 2020 review above traced its vanished cart discount to a conflict with a slide-out cart app, found by the merchant after eight hours. We cover the theme-code angle in sale badges without touching your theme code.

The manual fix: plan as if the app will be down

1. Know which mechanism your sale uses. If it is a native or app-created automatic discount, an outage costs you control but not the discount. If it rewrites prices, an outage can leave the catalog half-changed, and you need step 2.
2. Export your prices before anything runs. A product CSV export taken the day before is the only restore path that does not depend on the app. Our Black Friday bulk sale guide has the full checklist.
3. Start early and test on a quiet day. Schedule a rewrite sale to begin hours before shoppers arrive, so a slow queue finishes while nobody is looking, and run a small dress rehearsal the week before, including ending it.
4. Keep Shopify’s own discount as a fallback. An automatic discount you create in the admin needs no app at all; if the app is unreachable, you can still give shoppers the price you advertised at checkout, even if the strike-through on the product page is missing.
5. Confirm there is an “end now” you can reach. Where is the button, and does it still work if support is closed for the holiday?

How SafeSale handles it

SafeSale offers both mechanisms and is honest about the difference. The following describes how the app is built today.

• Default mechanism: a Shopify automatic discount. SafeSale creates the discount through the Admin API with the sale’s start and end times, backed by SafeSale’s discount Function. From that point Shopify applies it in the cart and checkout and switches it off at the end time; SafeSale’s servers are not involved in pricing a single cart. Ending the sale early deletes the discount. SafeSale requires an end date for this mechanism, so a sale can never be left running by accident.
• Opt-in mechanism: price rewrite with visible progress. When you choose to rewrite prices for the crossed-out effect, the work runs as jobs: snapshot every variant, write the sale prices, publish the badge and countdown, and later restore. The sale page shows counts of snapshots saved, variants written and variants restored, and an audit log with a row for each step. Writes are grouped per product and retried with exponential back-off when Shopify throttles them; a step that exhausts its retries marks the sale as failed and shows Retry now and Restore original prices instead of failing quietly.
• Scheduled work survives an outage. Start and end steps are database jobs with a due time. If SafeSale’s worker is not running when a sale is due to start or end, the job is picked up as soon as it is, and the end-of-sale restore writes the snapshotted prices regardless of how late it is.
• Badges and countdowns without a script host. The storefront badge and countdown are a theme app extension that reads app-owned metafields SafeSale sets when a sale starts and clears when it ends. There is no third-party script URL to time out.

What SafeSale does not claim: an uptime SLA, a fixed number of minutes for a rewrite of a given size (it depends on your plan’s rate limit and on Shopify), or that a rewrite sale can end while the app is unreachable. It cannot. If you need the crossed-out price on product pages and you cannot tolerate that dependency, start the rewrite early and keep the CSV export.

Next step

SafeSale is not yet publicly listed on the Shopify App Store. The landing page walks through both mechanisms and the live progress view. See how SafeSale runs a Black Friday sale.