GA4 Custom Alerts: How to Set Them Up and Where They Stop Working

GA4 doesn't have a feature called "Custom Alerts" the way Universal Analytics did. The thing that fills that gap is called Custom Insights, and it lives one click off the main reports panel. It's free, it does roughly what most teams need from a baseline alerting layer, and it has a small set of structural limitations that decide whether it's enough for your situation or just a starting point.

This guide walks through creating a Custom Insight in practice, the conditions actually worth configuring, and the point at which the native approach stops scaling.

What GA4 Custom Insights actually do

A Custom Insight is a condition you define on top of standard GA4 metrics. You tell GA4 something like "alert me when sessions decrease by more than 25% compared to the same day last week," and GA4 evaluates that condition on its scheduled cadence and emails you when it triggers.

The strengths are that it's free, it ships in the box, and it requires no third-party access to your data. The shape of the alerts is also straightforward: GA4 supports daily, weekly, or monthly evaluation; it supports comparison to the previous period or the same period in a prior week; and it can notify multiple email addresses.

The structural shape of what it doesn't do is also worth being clear about. It can't notify Slack. It can't run across multiple properties from a single configuration — every property gets its own setup. It uses fixed-percentage thresholds rather than statistical baselines, which means the same alert design that catches a real failure on Tuesday will fire every Sunday for ordinary weekend variance. And it has a 24-to-48-hour data-processing lag — a tracking failure that starts at 2pm Tuesday won't surface in a Custom Insight until Wednesday at earliest.

For one property with a single person watching it, those constraints are mostly fine. For anything wider, they're the reason the conversation about monitoring tools exists at all.

Setting one up

In GA4, go to Reports in the left sidebar, then click Insights at the top of the reports section. In the Insights panel, click Create. You need Editor access to the property — if the Create button isn't visible, that's the reason.

Choose "Custom insight." The other option, "General insight," is GA4's auto-generated observations and isn't configurable.

Set the evaluation frequency. Daily is the right answer for almost any alert that's meant to catch real problems. Weekly and monthly are for trend-level monitoring on metrics where day-to-day variance isn't meaningful — for most teams, those use cases are rare.

Define the condition. The structure is always the same: a metric, a condition type (decreases by more than, increases by more than), a numeric threshold, and a comparison period. The comparison period is the most important choice and the one most teams get wrong. "Same day previous week" is almost always the right baseline because it accounts for the day-of-week pattern most properties have. "Previous period" compares Sunday to Saturday and creates noisy alerts.

Add your email addresses under Notifications. Multiple addresses are supported; Slack isn't.

Give the insight a name that's descriptive enough to be useful in a triaged inbox. "Sessions drop >25% vs same day last week" is fine. "Sessions alert" is not.

Save. The insight starts evaluating on the next scheduled cycle.

Which conditions are worth configuring

The temptation with a flexible alerting system is to configure a lot of insights, which is the fastest way to make all of them functionally invisible. The compact, useful list is shorter than most teams set up.

Session volume drop is the foundation. Most properties want this — sessions decreasing by more than 25 to 30 percent compared to same day previous week, evaluated daily. This is the canary for tracking failures and major traffic events. If only one alert exists, this is it.

Conversion volume drop is the second one to add. Conversion tracking breaks silently and often — a form platform change, a thank-you page URL update, a redesigned checkout. A 30-percent drop in conversions compared to same day previous week catches most of these within the GA4 lag window.

If the property is e-commerce, revenue is worth a separate alert at a tighter threshold (20 percent rather than 25), because revenue tracking failures usually mean either money missed or attribution drifting, both of which are higher-stakes than session-volume changes.

Beyond those three, additional alerts usually produce more noise than signal. Bounce rate alerts trigger on UX changes that aren't always problems. Channel-level alerts fire constantly because channel mix is inherently noisier than aggregate metrics. Adding too many alerts converges toward the failure mode that Custom Insights was supposed to prevent — alert volume so high that real signals get ignored.

The right number of GA4 Custom Insights is closer to three than to ten. More than that, and you're training yourself to scroll past the email.

Where the native approach hits its ceiling

The 24-to-48-hour processing lag is the cleanest reason teams outgrow native alerting. A failure that starts at noon Tuesday and surfaces Wednesday afternoon is, in practice, a day-and-a-half of degraded data — and for paid campaigns running on broken conversion signals during that window, the cost shows up downstream.

The per-property configuration cost is the second one. Setting up three Custom Insights per property is manageable when you have one property. At twenty properties, it's sixty manual configurations, and any change to your alerting strategy means making the change sixty times. Most teams don't actually update their custom insights as their setup evolves — the configurations become artifacts of when they were created.

Email-only delivery is the third. For agency teams running multi-client workflows in Slack, an alert that arrives by email goes to a different attention surface than the one the team actually monitors. The alert technically exists. Operationally, it doesn't reach anyone in time to matter.

The fixed-threshold problem is the fourth, and the most subtle. Custom Insights can only compare to a fixed percentage. They have no concept of "this property normally varies by 18 percent week-to-week, so a 22-percent drop is barely a signal." Setting the threshold high enough to suppress false positives also raises the bar past which real, slower-moving anomalies (a conversion erosion of 18 percent that lasts six weeks) ever trigger.

When Custom Insights are still the right call

For all the limitations, GA4 Custom Insights are the right starting point in a specific situation: a single property, a single person monitoring it, daily attention to the GA4 interface as part of the regular routine, and a small set of conversion events where simple thresholds are actually fine.

That's not nothing. A lot of analytics setups are exactly that shape. For those, three well-configured Custom Insights — session volume, conversion volume, and revenue if applicable — cover most of the failure modes that produce client-facing problems.

The point at which it stops being enough is the point at which the configuration cost exceeds the value, or the operational layer around the alerts (routing, delivery, baseline awareness) starts mattering more than the detection logic itself. That point arrives faster than most teams expect, usually somewhere between the fifth and tenth property under management. Recognizing it when it happens, rather than continuing to patch native alerts past their useful range, is the difference between monitoring as a system and monitoring as a habit you keep meaning to fix.