Debugging Custom Events When They Don't Show in GA4 (2026)

Why isn't my custom event showing in GA4?

The seven most common causes ranked by frequency: (1) the dataLayer push isn't firing at all (typo in event name, wrong trigger, scope issue), (2) GTM trigger doesn't match the event name (case sensitivity, leading/trailing whitespace), (3) the GA4 Tag fires but the event parameter mapping is wrong, (4) the network request goes out but contains malformed data GA4 silently rejects, (5) DebugView shows the event but the parameter isn't a registered custom dimension (so it doesn't appear in standard reports), (6) standard reports just haven't settled yet (24–48 hours required), or (7) the event name conflicts with a reserved name that GA4 handles specially. Walk through these in order — the diagnostic is deterministic when you don't skip steps.

The seven-step diagnostic

Step 1 — Confirm the dataLayer push happens

Open Chrome DevTools → Console. Type:

You see the entire array. Look for your event by name. If it's not there, the push never happened. Causes:

• The trigger that should fire the push isn't firing (button click, page load, etc.)
• The push code has a typo
• The push happens before dataLayer is initialised (race condition)
• The push happens in a context that resets the array (SPA navigation reset)

Fix the upstream code. If the dataLayer doesn't have the event, nothing else can.

Step 2 — Verify GTM trigger matches

Install the Tag Assistant extension. Open it, navigate to the page where the event should fire, trigger the action.

Tag Assistant shows:

• Every dataLayer push
• Every GTM Tag fired
• The trigger that caused each Tag firing

Check whether your custom Tag fires when expected. If not:

• Trigger event name mismatch. Your dataLayer push says event: 'lead_submit' but the trigger says lead_Submit or leadSubmit. Case-sensitive.
• Trigger conditions filter out the event (e.g., page path filter that's too strict).
• Variable in the trigger has a typo or returns a different value than expected.

GTM Preview mode (the same Tag Assistant link from GTM admin) shows step-by-step what's happening. Use it.

Step 3 — Inspect the GA4 event configuration

Once the GA4 Tag is firing, click into it in GTM Preview. The Tag's event detail shows:

• The event name being sent to GA4
• Every event parameter being sent
• The configuration tag's measurement ID

Verify:

• Event name matches what you intend (no transformation happening between dataLayer and GA4)
• Event parameters include the fields you expect with the values you expect
• Variable references are resolving correctly (no undefined or [empty] values)

Common bug here: GTM Variable points to {{DLV - transaction_id}} but the dataLayer push has transactionId (case mismatch). Fix Variable or push to align.

Step 4 — Confirm network request fires

In DevTools Network tab, filter for collect. Trigger your event. A request to region1.google-analytics.com/g/collect should appear.

Click it. The URL parameters show:

• en (event name)
• ep.<param> (event parameters with ep. prefix)
• tid (measurement ID)

Verify the en parameter matches your intended event name. Verify all ep.* parameters are present. The presence of the request confirms it left the browser; the URL parameters confirm what data it carried.

If no request appears at all, GTM didn't fire the GA4 Tag despite Tag Assistant showing it firing. This indicates a Tag Assistant misalignment — re-check the GTM Preview from a fresh tab.

Step 5 — Check GA4 DebugView

In GA4 → Admin → DebugView, you should see the event arriving. To populate DebugView, your client must send the debug_mode: 1 parameter (gtag does this automatically when GTM Preview is active; Tag Assistant adds it to your session).

If your event name shows in DebugView, GA4 is receiving it. The remaining issue is reporting visibility.

If DebugView is empty:

• Your debug_mode parameter isn't being set
• The data is going to a different GA4 property (wrong measurement ID)
• The GA4 endpoint is being blocked by ad-blockers or network policy

Step 6 — Check Realtime report

In GA4 → Reports → Realtime, you should see the event in the Event count card.

Realtime shows last 30 minutes of activity. Latency: 30 seconds typical, up to 2 minutes during high traffic. If you see the event in DebugView but not Realtime, wait a few minutes and refresh.

If after 5+ minutes Realtime doesn't show the event, but DebugView does — likely a regional GA4 backend issue (rare). Wait 24 hours; standard reports should still receive the data even if Realtime had a temporary issue.

Step 7 — Check standard reports (24-48 hours later)

Standard reports settle 24-48 hours after the event date. If your event fires today and you check Acquisition reports tomorrow morning, the data may still be settling.

Wait at least 48 hours from the first event of a new event type before declaring "the event isn't appearing in reports." Many false alarms come from impatience.

If after 48 hours the event is in DebugView and Realtime but not in standard reports' event list, you've hit a known GA4 quirk: new event types can take up to 7 days to appear as filterable options in some reports. The data is being collected; it's just not yet a selectable filter value.

Step 8 (bonus) — Custom dimension registration

If the event appears in reports but a specific custom parameter doesn't appear in dimension dropdowns, you haven't registered it as a custom dimension.

GA4 Admin → Custom definitions → Custom dimensions → New custom dimension. Set the scope (Event/User/Item) and reference the parameter name. After registration, the dimension appears in reports' dimension picker — but only for events from the registration moment forward. Historical events don't get retroactive dimension breakouts in standard reports (BigQuery has them).

Common false alarms

Three patterns that look like bugs but aren't:

False alarm 1 — "It's been an hour and not in reports" Standard reports take 24-48 hours to settle. Realtime is the right surface for sub-hour validation. Don't conclude something's broken before 48 hours have passed.

False alarm 2 — "DebugView is empty in production" DebugView only shows events with debug_mode=1. Production users don't have this set unless they're using Tag Assistant. Use Realtime for production validation.

False alarm 3 — "Custom dimension shows 'not_set' for many events" Means the dimension isn't being populated on those events. Either the dimension was registered after the events fired (historical not_set), or the events don't include the parameter (real implementation bug). Check whether the events were sent from before registration date.