Shopify Black Friday Checklist: What Breaks at Peak

A Shopify Black Friday checklist that holds up at peak covers six engineering risks, not just promotions: discount rules after the end of Shopify Scripts, your integrations' API rate limits, duplicate and missing webhooks, overselling, tracking you can trust, and a freeze with a rollback plan. Black Friday 2026 is Friday, November 27 and Cyber Monday is November 30, so a team starting the week of October 12 has six weeks.

This is also the first Black Friday since Shopify Scripts stopped running on June 30, 2026, and since August 26, 2026, the date Shopify gave non-Plus stores to upgrade their Thank you and Order status pages. Discount logic and purchase tracking that worked last November may not exist in the same form today.

The ranking checklists for this topic are mostly marketing plans from app vendors: discount ideas, email sequences, hero products. This is the other half, built from Shopify's own documentation, read on October 12, 2026. Keplaris wrote it out of its Shopify e-commerce practice. We don't publish client order volumes or BFCM results, so no number below is a client number. Where we did arithmetic on Shopify's published limits, we say so.

Shopify Black Friday checklist: the short version

Work backwards from November 27: four weeks to find and fix, then a feature freeze, then a code freeze, then the weekend. Each week has one job.

The freeze dates are our suggestion, not a Shopify rule. They follow the order Shopify described for its own platform in a 2019 post on preparing for BFCM: a feature freeze where "most user-facing features won't be touched", then a code freeze where "only critical fixes can be deployed." Its 2025 readiness post puts it more strongly: "We don't use BFCM as a release deadline," and every architectural change happens "months before that critical window."

What changed since last Black Friday

Three things changed between BFCM 2025 and now, and each one can break a sale that worked last year: Scripts stopped running, and, for non-Plus stores, the Thank you and Order status pages moved to the new system, where pixels respect customer consent.

Shopify Scripts stopped running on June 30, 2026. Shopify's developer changelog (posted April 9, 2026) set two dates: editing and publishing new Scripts ended on April 15, and "all Shopify Scripts will cease to execute entirely" on June 30. If a Plus store ran tiered pricing, a free gift or a payment method rule as a Ruby Script, that rule hasn't run since the end of June. Its replacement is Shopify Functions. This will be the first BFCM where that logic runs on Functions, so test it as new code, because it is.

The Thank you and Order status deadline passed on August 26, 2026. Shopify's upgrade guide says "August 26, 2026 was the deadline for stores on a non-Plus Shopify subscription plan to upgrade," and that the Additional Scripts box has been view-only since August 28, 2025. On upgrade, the old pages and "any existing customizations on those pages are replaced with the new versions." A conversion tag pasted into Additional Scripts years ago doesn't fire on the new pages. Shopify's guide also offers a customizations report under Settings, then Checkout, that lists what your old scripts did. Our checkout extensibility migration guide covers moving tracking to a custom pixel.

Pixels wait for consent. Shopify's web pixels documentation says that "in regions where customers must consent to tracking, app extension callbacks are executed only after consent is given." Shopify then replays earlier events, but a shopper who never consents never reaches your ad platforms. A gap between pixel purchases and Shopify orders is expected; the question is whether it is the same size as before.

How to test discount stacking on Shopify

Test every discount you plan to run in combination with every other one, on a development store or an unpublished duplicate theme, and write down which discount won. Shopify's discount combination rules are specific, and the defaults surprise people at peak.

The rules that matter most for a Black Friday sale, quoted from that page:

• "You can have a maximum of 25 active automatic discounts. This total includes app-based discounts."
• Customers can use "a maximum of 5 product or order discount codes and 1 shipping discount code on the same order."
• When discounts can't combine, "the best discount for the customer's cart is always applied."
• Product plus order and order plus order combinations are only for eligible stores (no checkout.liquid customizations, no Licensify app). Several product discounts on the same line item are Shopify Plus only.
• Two percentage order discounts are both calculated on the original subtotal: 10% plus 20% on $100 comes to $70, not $72.
• Combinations work only on the Online Store, the Storefront API and Shopify POS, and "aren't available for checkouts on Facebook, Instagram, Google, or other external checkout platforms."
• On every plan except Plus, products in a Buy X get Y discount are ineligible for further product discounts.

Here is the matrix we'd run. Fill the last two columns from your own test orders.

Run each promoted discount through guest checkout, a signed-in account and an accelerated wallet such as Shop Pay, because a code that works in one path can fail in another.

We present this as a template rather than results: we didn't run it on a development store for this post, so we report no outcomes. The rules column comes from Shopify's help page on October 12, 2026. If a row fails, fix it in week 5, not on Thanksgiving.

One more check for Function-based discounts: Shopify's Functions overview says stores on any plan can use public App Store apps that contain Functions, but "only stores on a Shopify Plus plan can use custom apps that contain Shopify Function APIs." It also "strongly recommends Rust as the most performant language choice to avoid your function failing with large carts." Add a large cart, such as 40 line items, to the matrix. How much room a Function has depends on the language and the cart: in our Shopify Functions benchmark, a JavaScript build of a tiered discount used 77% of the instruction limit at 200 lines, against 13% for the same logic in Rust.

Will your apps and integrations hit Shopify's API rate limits?

Probably not at normal volume, but an order sync that spends many points per order can fall behind at peak, especially on Standard plans. Shopify's GraphQL Admin API rate limits page sets the budget by plan, per app and store: "Calls from one app don't affect the rate limits of another app, even on the same store."

The same page says a mutation costs 10 points by default, an object 1 point, and "a single query may not exceed a cost of 1,000 points, regardless of plan limits." Limits are a leaky bucket, so "short bursts are fine as long as your average cost stays under the restore rate." Bulk operations "don't have the max cost limits or rate limits that single queries have," which is why exports and catalog jobs belong there and not in a loop of single queries. Shopify's general limits page adds two lines for peak traffic: "Shopify may temporarily reduce API rate limits to protect platform stability," and "the recommended backoff time is one second."

Our arithmetic, not a test. Here is what those limits mean for one app that syncs every new order to an ERP or 3PL. Assume each order costs one query and two mutations. We assume the query costs 20 points (yours will differ; read extensions.cost in the response), and mutations use Shopify's default of 10 each. So 40 points per order. A heavier sync, one 50-point query plus four mutations, costs 90.

These are sustained ceilings for one app, with nothing else spending its budget. Retries, inventory updates and fulfillment writes from the same app come out of the same bucket. If your best minute last year came near the heavier column, either lower the cost per order (fewer fields, fewer mutations) or move bulk reads to bulk operations. If API headroom is the only reason you're looking at Plus, our Shopify Plus vs Advanced comparison shows what the upgrade costs against what it saves in fees.

Ask each app vendor that writes to your orders three questions: what does one order cost you in points, what do you do when throttled, and do you queue or drop work you couldn't send? A vendor that retries instantly in a loop will burn the bucket it shares with nobody but itself. We cover backoff and 429 handling from the API owner's side in our SaaS API rate limiting guide.

How to handle duplicate and missing Shopify webhooks

Assume you'll get some webhooks twice, some out of order and some not at all, and build for all three. Shopify's own docs say so: "Webhook delivery isn't always guaranteed," and "Shopify doesn't guarantee ordering within a topic, or across different topics for the same resource" (webhooks overview).

The Shopify-specific rules, from the verify deliveries page and the overview, all of which matter more at peak:

• Dedupe on X-Shopify-Webhook-Id. "Your app might receive the same webhook more than once, for example after a network timeout or a retry." X-Shopify-Event-Id is for correlating deliveries from the same merchant action, not for dedupe.
• Answer fast. "Shopify has a one-second connection timeout and a five-second timeout for the entire request." Store the delivery in an inbox table, return 200, and let a worker process rows where processed_at is null.
• Retries are finite. Shopify "retries 8 times over the next 4 hours," and after 8 consecutive failures the subscription "is automatically deleted if it was configured using the Admin API." An endpoint that is down for an afternoon can lose its subscription in the middle of the sale.
• Compare against the copy you hold, and decide ties. Shopify suggests X-Shopify-Triggered-At or the payload's updated_at to organize webhooks. Apply an update only if its updated_at is strictly newer than the copy you hold, and when the two are equal, re-fetch the order from the Admin API instead of guessing.
• Reconcile. "For redundancy, use reconciliation jobs to periodically fetch data from Shopify so that your app stays consistent with Shopify's data." On the sale weekend, run one every 10 to 15 minutes for orders updated since its last checkpoint.

The receiver design behind those rules (a UNIQUE insert committed with the side effect, how long to keep the keys, and why ordering by a timestamp alone fails on same-second ties) is tested in our webhook idempotency and retries guide, with a script you can run before the freeze.

How to prevent overselling during a flash sale

Turn off "Continue selling when out of stock" on every limited item, keep a buffer on items your 3PL or ERP also sells, and shorten the sync interval for the weekend. Shopify's out of stock help page defines the setting: "An item is out of stock when inventory is tracked and the inventory level is at zero or below," and you can select Continue selling "only when you turn on the Inventory tracked setting."

Three things to audit:

1. The policy, per variant. Export products to CSV. In Shopify's product CSV format, the "Continue selling when out of stock" column is deny by default and continue to "allow the variant to be purchased after its inventory level reaches 0." Filter for continue and decide variant by variant. A blank Inventory tracker means the variant isn't tracked at all, so it can't sell out.
2. POS and locations. The setting "doesn't apply to orders placed from Shopify POS," and if the location that fulfills online orders is at zero, the item shows as out of stock online even when another location has stock.
3. The external source of truth. If an ERP or warehouse sets Shopify's stock levels on a schedule, every interval is a window where both systems can sell the last unit. Hold back a buffer on your top sellers equal to roughly one interval of peak sales, and confirm the sync's API cost fits the budget in the table above.

Large catalogs have one more limit: "Once a store has 500,000 product variants, no more than 10,000 new variants can be created per day, on any API" (rate limits page). If a Black Friday bundle launch adds thousands of variants, load them in week 4.

Tracking you can trust on the day

Decide now which number is the truth on Black Friday: Shopify orders. Then measure how far each analytics and ad tool sits from it on normal days, so a gap on the day means something. On the upgraded Thank you and Order status pages, tags in Additional Scripts no longer fire, and consent rules hold back pixel events by design.

The check takes an afternoon in week 3:

Write the normal gap into the runbook. If, for example, GA4 runs 15% below Shopify on ordinary days and 40% below on Black Friday morning, something broke. Our Shopify CRO playbook explains why we fix the event layer before any optimization work.

Can you load test a Shopify store?

Not the live storefront, unless Shopify gives you written permission. We found no Shopify help or developer page that allows merchants to load test a live store. Shopify's Terms of Service (last updated August 1, 2026) say in Section 1.9: "You agree not to access the Services or monitor any material or information from the Services using any robot, spider, scraper, or other automated means." A load test is automated access by definition.

Shopify load tests its own platform. Its 2025 readiness post says that "from April through October we ran five major scale tests," reaching "146 million requests per minute and 80,000+ checkouts per minute" by the fourth. That capacity is Shopify's job, and the parts that are your job can be tested safely:

• Your own endpoints. Replay a peak hour of recorded webhooks against a staging copy of your webhook receiver and middleware, at 3 to 5 times speed.
• Your sync logic. Run the order sync against a development store with a seeded backlog and confirm it drains without throttling errors.
• App vendors' capacity. Ask in writing what volume they've handled and how they behave when throttled.
• Theme speed. Use Lighthouse or Shopify's speed reports on a duplicate theme for page weight; that measures one visit, not load. Our guide to speeding up a Shopify store lists what to cut.

Code freeze, rollback and on-call

Make every change you can undo before the freeze, and make undo a rehearsed step, not a hope. On Shopify, rollback means a duplicate theme, a short list of who can publish, and knowing which apps you can switch off without breaking checkout.

• Duplicate the live theme on the day the code freeze starts. Shopify's help suggests a duplicate as a backup "so that you can discard your changes." Shopify won't let you duplicate a theme once 20 themes are in your admin, so clear old ones first.
• Know the limits of file history. The code editor's Timeline view can restore a single file, but per Shopify's theme code docs, "it doesn't restore an entire theme," "Timeline history is finite," and assets such as CSS and JavaScript have no Timeline. The duplicate theme is the real rollback.
• Limit who can publish. During the freeze, one or two named people can publish themes, install apps or change checkout settings.
• Keep an on-call rota for Black Friday and Cyber Monday with names for store, integrations and payments. Shopify's own plan for 2025 included "Incident Manager OnCall (IMOC) teams with 24/7 coverage and escalation paths."
• Bookmark status pages: Shopify Status, plus your payment provider, 3PL and the apps that touch checkout.

This is the same staged, reversible approach we describe for launches in our Shopify commerce case study.

What to watch on Black Friday

Watch four numbers against last year and against an ordinary Friday: orders per minute, checkout errors, webhook backlog and discount misfires. Shopify's BFCM 2025 release, filed with the SEC, said shopping across all Shopify merchants "peaked at 12:01pm EST on Black Friday," at a record $5.1 million per minute, within $14.6 billion of BFCM sales. Shopify adds that "all data presented here (including worldwide sales) is approximate," "unaudited and is subject to adjustment," and that its "methodology underlying the data may vary year-on-year." Use the timing to plan cover around midday Eastern on November 27, not as a forecast for your store; your peak follows your own email sends and time zones.

What this checklist can't tell you

It can't tell you your store's peak, because that depends on your traffic, offers and send times, and we have no store data to share here. The capacity table is arithmetic on Shopify's published limits with an assumed cost per order, not a measurement. The discount matrix is a template, not test results. Shopify's rules here were read on October 12, 2026; plan names, limits and discount rules change, so re-check the linked pages in week 1.

If you'd like a team to run this checklist on your store, from the integration audit to the weekend runbook, that's the work of our Shopify e-commerce practice. If you're deciding who to bring in, our guide to Shopify developer cost compares rates by hire type.