Black Friday 2026: Your Peak Traffic Tracking Checklist

On Friday, November 27, 2026, your sGTM server probably will not go down. Really. Infrastructure failure is the least likely risk of your Black Friday. What breaks on peak day is something else: the Cloud Run bill that triples without warning, the GA4 to BigQuery export that suspends once you cross a million events, the reports that flip to (other) at the exact moment your CEO looks at the dashboard, and the fact that Google freezes deployments all weekend. This guide is a dated Black Friday tracking checklist to get your setup ready with no nasty surprises, to run between now and November 18.

Let me be upfront: this article does not sell fear. Most server-side setups handle the peak without flinching. The real danger is not availability, it is budget and analytics. And that is exactly what Google’s official documentation on high-traffic events does not say: it recommends “reserving capacity” and “checking your quotas” without giving a single number, and it has not been updated since October 9, 2024. We are going to give the numbers, the order of operations, and above all the three things it never mentions.

What actually breaks on Black Friday peak day

Before you touch anything, let us put the risks in order. On a properly sized sGTM setup, server availability is rarely the problem: Cloud Run scales horizontally, and a server-side tag manager is a light, predictable workload. What hurts are three much quieter things.

The first risk is cost. Your bill follows your traffic, and traffic multiplied by five on a Friday means a bill multiplied by five that day. Nobody notices until the invoice lands in December.

The second is data loss. Some GA4 and BigQuery thresholds trigger on volume, and peak day is precisely when you cross them for the first time. You lose the data for the single most important day of the year.

The third is unreadable reports. Cardinality explodes, item_name and page_location spill into (other), and your e-commerce reports become useless right when everyone wants to look at them.

Server outage: unlikely. Cost, data loss, unreadable reports: that is where your prep time should go. We handle each block in order.

Block 1, the sGTM infrastructure: calculate before you tune

If you have not moved to server-side yet, this article is the wrong starting point: begin with the guide to migrating to server-side GTM, then come back here. For everyone else, the rule of this block fits in one sentence: calculate first, tune second. Provisioning blindly means either paying for empty capacity or getting overrun.

Calculate your projected peak volume

The question you need to answer is not “how many instances?” but “how many requests per second at peak?”. The method is simple. Take your peak requests per second on a normal day (visible in Cloud Run metrics), apply your expected Black Friday multiplier (look at last year, often between three and six), then divide by the observed capacity of one instance.

An example, presented as an example and not a universal truth: if one instance comfortably handles 50 requests per second in your setup, and you project 600 requests per second at peak, you need roughly 12 instances running simultaneously, with headroom on top. The exact number depends on your containers, your outbound tags and your region. Do not copy the 12, redo the calculation with your own metrics.

Set min instances and max instances

Google’s documentation is clear on the principle, less so on the numbers. min instances should be set to absorb traffic without letting Cloud Run cold-start instances mid-peak (a cold start adds latency at exactly the wrong moment). In practice, raise min instances to your projected weekend trough at least, and push it closer to the peak if your budget allows, to avoid any cold start during the campaign.

max instances is your safety net. Set it above your calculated peak, with margin, but not to infinity: it is also your cost ceiling in case of an anomaly or an attack. A max instances left at default is an uncapped bill.

1 vCPU per instance, and why adding more breaks autoscaling

Classic, counterintuitive trap: keep 1 vCPU per instance. Adding vCPUs to “handle more” is often a mistake in server-side, because Cloud Run autoscaling triggers on CPU usage. Bigger instances stay underused for longer, the autoscaler is slow to add instances, and you end up with less parallelism at peak. You want many small 1 vCPU instances, not a few big ones. Also enable CPU always allocated for a service that receives continuous traffic, to avoid stalls.

Check Cloud Run quotas before requesting an increase

Here is the step everyone forgets, and it bites hard: your regional Cloud Run quotas (max instances per region in particular) can cap below what your max instances asks for. Check them now, in the GCP console. If a quota increase is needed, it goes through a Google ticket that is not instant, and above all: it will not be processed during the late-November freeze window. A quota request filed on November 24 is a request that will not land in time.

Update the sGTM image to the latest version before the freeze

Last point of this block: update your sGTM Docker image to the latest stable version (4.4.0 dates from July 22, 2026, per the server-side tagging release notes) well before the freeze window. You do not want to discover a version bug at the worst possible moment, nor attempt an image update during the weekend when Google freezes infrastructure restarts. If you run many outbound CAPIs, keep in mind they multiply server requests at peak: our article on Meta CAPI deduplication and Event Match Quality breaks down what each conversion actually sends server-side.

Block 2, cost: the real risk

This is where the true Black Friday surprise happens, and it is also what Google’s docs say nothing about. Your tracking cost follows your traffic, mechanically.

If you self-host on Cloud Run, the bill climbs with the number of instance-seconds consumed. Set a GCP budget alert now, not in December: pick a realistic monthly threshold that includes the peak, with alerts at 50%, 90% and 100%. It does not cap spend, but it warns you before the invoice.

If you use a managed host, the trap is different and nastier: most bill in request tiers, and a peak bumps you up a tier, sometimes for the whole month. That is exactly the “request-counting trap” I detail in the article on how much server-side GTM really costs. Check exactly how your plan behaves on overage: pay-as-you-go, tier locked for the month, or a cutoff. The Stape vs Addingwell comparison covers each host’s billing logic, useful for anticipating your November invoice.

Finally, if you run a direct BigQuery export from sGTM, the peak also inflates your storage and streaming-insert costs. It is not the heaviest line item, but it belongs in your budget alert.

Block 3, data and reports

Infrastructure holds, the bill is monitored. What remains is the sneakiest risk: losing or garbling the data of the most important day of the year.

The GA4 BigQuery export and the million limit

Here is data trap number one. On a standard GA4 property (not 360), the BigQuery export is capped around a million events per day, and beyond that, the day’s export can be suspended. Guess which day you cross that threshold for the first time? November 27. You lose the export for the richest day of the year, with no clear alert.

Two defenses. Check your daily event volume right now: if you are already near 800,000 on a weekday, the peak will blow past the threshold for sure. And above all, consider the direct BigQuery export from sGTM, which bypasses the million limit by writing from the server, independently of the standard GA4 connector. It is the most robust defense for a big peak, but it goes in beforehand, not on the day.

The cardinality that pushes your items into (other)

When volume explodes, the cardinality of your dimensions explodes with it. GA4 has a ceiling on distinct values per dimension per day, beyond which it groups the overflow into an (other) row. On peak day, with thousands of different item_name, item_id or page_location values, your standard e-commerce reports can become unreadable, everything landing in (other). Check the cleanliness of your e-commerce implementation now: the GA4 e-commerce tracking guide via GTM covers items array best practices and how to keep cardinality under control. For fine-grained peak analysis, plan to go through BigQuery, which has no such cardinality limit.

Data thresholding and Google Signals

Another side effect: data thresholding. When Google Signals is active, GA4 hides report rows whose counts are too low to preserve anonymity. Counterintuitively, very high volume does not protect you: fine-grained segments (a rare combination of device, region and source) stay masked. If you need full granularity over the period, BigQuery export is again your safety net, because it does not apply thresholding.

Do not touch the conversion window mid-campaign

Golden rule: do not change the conversion window during the campaign. Changing that value mid Black Friday makes your comparisons uninterpretable and disrupts attribution at the worst moment. If you are wondering about the right setting, settle it now, before the peak: see which GA4 conversion window to choose. After that, hands off.

And while we are on setup hygiene: the best time to fix your configuration mistakes is September, not November. Run your property through the GA4 audit of configuration mistakes to fix while you still have time to test.

Google’s freeze window

A point almost nobody plans for: Google freezes part of its ecosystem during the Black Friday and Cyber Monday weekend. Concretely, non-essential code changes and restarts are paused on the GTM side, and Google Cloud pauses certain infrastructure updates, deployments and lifecycle operations over the period. Operational translation: the fix you wanted to push on Friday morning may not go out, and the quota increase you requested the day before will not be processed.

The consequence is simple and it reshapes your whole plan: your own freeze must start before Google’s. Assume everything must be in place, tested and deployed by the evening of November 18. From then on, you do not touch your infrastructure or your critical tags, barring a true emergency. Google’s recommended preparation window runs from one week before Thanksgiving to two days after Cyber Monday, that is November 19 to December 2: this is your read-only vigilance period, not a build phase.

The Black Friday calendar, action by date

Here is the dated checklist. Print it, tick it, share it with the team.

The morning after, November 30

The weekend is over. The real Monday question is not “how much did we sell” (the business already knows) but “did we measure everything correctly?”. Look at three things. First, the BigQuery export: is there a gap on November 27 or 28? A missing or truncated daily table signals a suspended export. Second, the share of (other) in your weekend e-commerce reports: if it jumped, your cardinality overflowed and fine analysis will go through BigQuery. Third, the gap between your GA4 conversions and your ad platforms, to spot a server signal loss.

If something is off, do not guess: the GA4 missing data diagnosis lays out how to tell a Google bug from a problem in your own tracking. That is the right reflex before concluding that “GA4 lost sales”.

In short

Your Black Friday tracking is not decided on November 27, it is decided now. Server outage is a false problem; the real ones are cost, data loss and unreadable reports. Three moves beat all the rest if you only keep three: set your budget alert this week, check your event volume against the million threshold before it is too late, and finish your entire deployment by November 18 because Google will freeze before you do. The rest is arithmetic and calendar discipline. And if you would rather hand off the pre-peak audit, that is exactly the kind of engagement you prepare in September, not the night before.