Google Tag Manager Now Shows gtag config as an Event. Check Your Wildcard Triggers.

What changed on October 8

Google's Tag Manager release notes for October 8, 2026 carry a short entry with a real blast radius. The first half:

"all Google Tag Manager (gtm.js) container snippets will initialize on container load, regardless of any gtag('config') commands."

The second half is the one to act on:

"config commands will now surface in the dataLayer as visible gtag.config events. If your Google Tag Manager containers use wildcard custom event triggers, this change may cause those tags to fire."

Nothing breaks loudly. A tag that used to wait for a real event can now fire on an event it never saw before.

Who is exposed

Containers with a Custom Event trigger that matches event names by regular expression with a broad pattern. The textbook example is .*, which matches every event name, including the new gtag.config.

People build these on purpose. A catch-all trigger is a quick way to log every event, or to forward everything in the dataLayer to a second analytics tool. It's written against the events that exist the day it's built. When a vendor adds a new event, the trigger quietly widens to include it.

What it looks like when it bites

These symptoms are illustrative. We don't have a count of affected containers, and neither does anyone else yet:

• Event counts go up with no change in traffic.
• Conversions start to double up where a conversion tag sits on a catch-all trigger.
• A tag that used to wait for an interaction fires on page load.

No error appears anywhere. The first sign is usually a report that looks better than it should, weeks later. 5 Signs Your Conversion Tracking Is Broken covers how drift like this tends to surface.

The five-minute check

1. Open the container and list your triggers. Look for any trigger of the Custom Event type.
2. For each one, check whether the event name uses regex matching, and whether the pattern is broad enough to match an event name you didn't plan for.
3. Note which tags use those triggers.
4. Open Preview mode, load a page, and look for gtag.config in the event timeline. Click it and see which tags fired on it.

If nothing fires on gtag.config, you're done. If something does, you've found it before your reports did.

The fix

Narrow the trigger rather than deleting it. The general approach: keep the broad match, but set the trigger to fire only on some custom events, with a condition that the event name does not equal gtag.config. Re-run Preview to confirm the tag no longer fires on it.

If a catch-all trigger only exists to feed a logging tool, ask whether it still needs to be a catch-all. A list of named events is longer to write and much harder to break.

Publish the fix from a clean workspace. Your GTM Hotfix Went Into the Default Workspace explains why a quick fix can ship more than you meant it to.

Why this keeps happening

Catch-all triggers depend on a list of events that someone else controls. Google adds events, vendors add events, and the trigger follows. This change is the latest step in Google's move toward the Google tag, which the 2026 migration checklist covers in more detail.

The only reliable way to see this kind of drift is to watch event volume per tag over time. A jump with no matching change in traffic is the signal.

Check today, then watch the volume

Run the five-minute check on every container that feeds reporting or bidding. Then put event-volume monitoring on the ones that matter, so the next silent change shows up as a number instead of a surprise.

Want a second pair of eyes? We review GTM containers for exactly this kind of exposure. Book a GTM container review.

Part of the guide: Analytics Tagging: Build, Govern and Monitor Your Tags