When you publish a new GTM workspace version, the change propagates within seconds, but during those seconds individual requests can hit the old version, the new version, or neither. The "neither" case is rare but real, and it is the reason serious teams schedule publishes outside peak traffic.

What can go wrong during a publish

For a few seconds (occasionally up to a minute), the GTM CDN serves a mixed state where some requests get the old config and some get the new. If a tag was renamed or removed, requests for the old tag are served the new config and silently fail.

For server containers, the same thing applies: the runtime fetches the latest config periodically, and during the window between when the new version is published and when your container picks it up, you have a state mismatch. SprTags pulls config every 60 seconds; self-hosted on App Engine the default is also 60 seconds.

Pick the right window

For consumer sites in Europe, the lowest-traffic window is typically Tuesday morning around 4-6 AM CET. For US-only sites, the equivalent is Sunday or early Monday morning. For global sites, the Tuesday morning slot is often least bad in aggregate.

Avoid: Friday afternoons (limited time to recover before weekend), Monday mornings (highest weekly traffic), any day before a sale or campaign launch.

Use named versions

When publishing, name the version with what changed and why. "Added meta_capi_purchase tag for cyber monday" is useful three months later. "Update" is not.

If something goes wrong, the rollback is to publish a previous named version. The named description is what helps you pick the right one without reading every diff.

For high-stakes changes

If the change involves moving a tag from client-side to server-side, removing a destination, or changing dedup logic, do it in two stages. First publish the additive change (new tag added but not yet replacing the old one). Verify for a day or two. Then publish the removal of the old tag.

This avoids the case where the new tag has a bug and you do not notice until the old tag is already gone. Two-stage publishes take longer but turn an "incident" into "I noticed and rolled back."

CI for publishes

If your workspace changes are frequent, consider a CI workflow that publishes on a schedule (say, weekly Tuesday morning) rather than on demand. Combined with named versions and an approval step, this is the closest you get to deploying tag manager changes safely. A quarterly audit on top keeps the workspace lean enough to publish quickly.