Your wildcard trigger now fires on gtag.config

The symptom arrives without a cause. A tag that used to fire on one event now fires on page load as well, or twice on a page where nothing was pushed, and nobody has touched the container. The version history is clean. Preview mode shows the tag firing and calls that healthy, because by its own rules it is.

What changed is not in the container. It is in how Tag Manager handles a call your page has probably made for years.

What Google changed

Google’s release note of 8 October 2026 says two things. Every gtm.js container now initialises when it loads, whether or not the page sends gtag('config'). And those config commands “will appear in the dataLayer as gtag.config events” — with a warning, in the same note, that this may cause tags on wildcard Custom Event triggers to fire.

The help article the note links to is narrower and more practical. It describes the setup Google calls unsupported: a gtm.js snippet loaded with a Google tag ID — G-, AW- or DC- — and configured through gtag('config'). Those snippets are being changed to stop waiting for config commands at all, and the containers affected were told by email.

Neither page says what fields a gtag.config event carries. This guide does not guess.

Which triggers catch it

Any Custom Event trigger with Use regex matching on and a pattern that gtag.config satisfies. The obvious ones are .* and .+. The less obvious ones were written to catch a family and catch this by accident: .*config.*, ^g, or anything built to match “events with a dot in them”.

Two places are worth checking before anything else: tags that send data somewhere — a pixel, a conversion, a Custom HTML beacon — because a stray fire there is a stray hit in someone’s report; and tags that run code with side effects, because those fire on the new event as happily as on the one they were written for. Reading the container lists every trigger and its condition, which is faster than opening each one in the interface.

Seeing it in Tag Master

This is the part to know before you go looking. The Events only view is on by default, and it is built to show what the site did rather than how the tag was set up — so it leaves out gtag('config'), gtag('js') and gtag('get') calls. Event and consent calls stay. That is the right default on an ordinary day, and on this day it hides the one push you are looking for.

Open View above the list and untick Events only, and the config calls appear in order with everything else the page pushed. What you see is the call the page made — gtag('config', 'G-…', {…}) — and the tag hit that follows it in the Network tab. The gtag.config name is how Google says Tag Manager now treats that call; it is the name the trigger is matched against.

Fixing it

1. Exclude system events from the catch-all. Add a condition to the trigger: Event does not match RegEx ^(gtm|gtag)\.. That keeps the wildcard and removes every event Tag Manager or the Google tag produces on its own.
2. Better, name what you mean. A catch-all trigger on a tag that sends data is a bet that no new event will ever reach the container, and this change shows the bet can be lost without anyone touching the container. A list of the event names you actually want cannot be widened by Google.
3. If you are on the unsupported setup, move off it. Google’s help article gives two ways: put the Google tag (gtag.js) snippet with its tag ID on every page, or keep the GTM snippet with its GTM- ID and deploy the Google tag inside the container.

Then load a page and check twice: that the config call is there, and that nothing you did not mean fired straight after it. Debugging from the requests rather than the preview is the faster of the two checks, because the stray hit is right there on the wire.

The direction this is going

This is one of three changes in a few months that bring the Google tag and Tag Manager closer together. In July a container’s ID started deciding what it may run. On 12 October an opt-in upgrade let a container send to Google without loading gtag.js at all. The news page keeps the list, with a line on what each one changes when you are the one debugging it.

Questions

What is the gtag.config event in Google Tag Manager?

It is how Tag Manager now treats a page’s gtag('config') command. Google’s release note of 8 October 2026 says config commands “will appear in the dataLayer as gtag.config events”. Google has not said what fields the event carries.

Why did my GTM tag start firing on every page?

If its trigger is a Custom Event whose name is a regular expression that matches anything — .*, .+ and the like — it now matches gtag.config as well, once per config call on the page. Google warns about exactly this in the release note.

How do I stop a Custom Event trigger matching gtag.config?

Add a condition to the trigger: Event does not match RegEx ^(gtm|gtag)\.. Better still, replace the catch-all with the event names you actually mean, so a new system event can never reach a tag that sends data.

Are sites that only use the gtag.js snippet affected?

Not by the trigger problem. A page with no gtm.js container has no Custom Event triggers to fire. Google’s help article names the gtag.js snippet on every page as the supported way to keep gtag configuration code.

The rest of this group: Containers and triggers

• How to debug GTM without Preview mode
• Ghost any GTM container: reading what a site publishes
• How to inject a GTM container into any website
• A GTM click trigger the next deploy will not break
• Tag Assistant alternative in 2026

More in Containers and triggers