Guide 17 · Debugging · GA4 + Tag Manager
The event is in Realtime but not in the reports: separate arrival from processing
Realtime shows the past 30 minutes; standard reports take 24 to 48 hours. An event in Realtime and missing from the standard report is in processing, not lost — unless 48 hours have passed.
After the steps below, the event is confirmed in Realtime, the send time is written down, and the standard report is judged only after 48 hours.
Download the check: the debugging check (JSON) (MD5 585fd58ea7d41c44d809a8c6a730b470, 434 bytes). It lists the checkpoints from this guide and the worked check, with the figures recomputed. The file was built for this guide and validated structurally — it was not exported from a live container or a live property.
What you need
- The event in Realtime. Open the Realtime report and find the event by name; this is the starting fact.
- The send time, written down. The hour and date, so the 48 hours can be counted.
- The standard report where it should land. The Events report, or the report built on the event.
- DebugView as a second witness. The event with its parameters, in case Realtime alone is doubted.
The trace
The worked check: the figures below were recomputed before publication, and the note under the table shows the working.
| Check | Figure |
|---|---|
| Events in Realtime during the test | 7 |
| Events in the standard report at hour 6 | 0 |
| Events in the standard report at hour 30 | 7 |
| Events still missing at hour 49 | 0 |
Seven events were in Realtime during the test and 0 were in the standard report at hour 6 — 7 minus 0 is 7 events in processing. At hour 30 the standard report showed 7 events, so 7 of 7 arrived, inside the 24 to 48 hour window. At hour 49, 0 events were still missing.
- Confirm the event in Realtime. Open the Realtime report and find the event by name. Realtime shows user activity during the past 30 minutes. If the event is here, GA4 has received it, and the standard report is a question of processing time, not of collection.
- Confirm the parameters in DebugView. With debug mode on, find the same event in DebugView and read its parameters. A Realtime event with the wrong value or the wrong currency is not a processing problem — it is a parameter problem, and the standard report will carry the same wrong values when it arrives.
- Write down the send time. Many reports and explorations can take 24 to 48 hours to process data. Write the hour and the date. Without a written time, every later check becomes a guess about whether enough time has passed.
- Check the standard report after 24 hours, and call it at 48. Look at the standard report the next day. If the event is there, the gap was processing. If it is still missing after 48 hours, processing has expired as the explanation — go back to the checkpoints: the trigger, the Measurement ID, the filters, and consent.
- Check the report definition before you declare it missing. A standard report built on a filter, a comparison, or a date range that excludes the event will hide it forever. Widen the date range to include the send date, remove the comparison, and look again before concluding the event never arrived.
Dead ends
DEAD END — THE DATE RANGE EXCLUDES THE EVENT. A report set to last week cannot show an event sent today. The most common reason an event is in Realtime and not in the report is the report's own date range. Set the range to include the send date first.
DEAD END — CALLING IT MISSING AT HOUR 6. Six hours is inside the processing window, not past it. Declaring the event lost at hour 6 and rebuilding the tag wastes the fix and creates a second, duplicate tag while the first event is still on its way.
DEAD END — A COMPARISON THAT HIDES THE EVENT. A comparison in the report splits the rows by a dimension, and an event with no value for that dimension can fall out of view. Remove the comparison and read the plain report before you conclude the event is gone.
End state
The event confirmed in Realtime and DebugView, the send time written down, and the standard report judged on its own clock: present after 24 hours means processing, missing after 48 hours means a real break. Arrival and processing are two different facts, and now they are checked separately.
Sources
- Analytics Help — Confirm that you are collecting data — Realtime versus DebugView, the past 30 minutes in Realtime, and the 24 to 48 hour processing time for reports and explorations
- Analytics Help — Monitor events in DebugView — DebugView as the second witness, showing the event with its parameters
Checked 11 November 2026. The click paths above are the ones in Google's help pages, opened 11 November 2026. What was run: the report counts, recomputed — 7 events in Realtime, 0 in the standard report at hour 6, 7 of 7 at hour 30, and 0 still missing at hour 49. No step in this guide was run inside a live Analytics property or a live Tag Manager container, because both need a Google sign-in and this site does not sign in as anyone. Google moves menu items without warning; if a path on this page no longer matches, the linked help page is the current map.