How to Set Up a PostHog Alert for Your Website

Analytics dashboards are useful, but they only help when someone checks them.

PostHog alerts make your website analytics proactive. Instead of discovering a tracking issue, traffic drop, signup problem, or checkout break days later, you can get notified when a key metric moves outside the range you care about.

That makes alerts especially valuable for CRO, ecommerce, SaaS, lead generation, and paid acquisition. If your homepage traffic drops, your demo form stops firing, your checkout completion event disappears, or your conversion rate suddenly falls, you want to know quickly.

This guide shows how to set up a PostHog alert for your website, choose the right metric, configure alert conditions, send notifications to Slack or a webhook, and validate that the alert is actually useful.

What Are PostHog Alerts?

PostHog alerts watch an insight and notify you when the metric crosses a condition you define.

You can use alerts for:

1. Sudden traffic drops.
2. Signup or lead form failures.
3. Checkout completion drops.
4. Purchase volume changes.
5. Error event spikes.
6. Funnel conversion decreases.
7. Pageview anomalies.
8. Experiment or feature rollout monitoring.
9. Tracking implementation failures.
10. Revenue or product usage anomalies.

In PostHog, alerts are created from an insight. That means you usually start by building the chart or funnel you want to monitor, then attach an alert to it.

When Should You Use an Alert?

Use a PostHog alert when a change in the metric should trigger action.

Good alert candidates:

1. Website visits fall below the normal daily range.
2. Signup submissions drop to zero.
3. Purchases fall below a minimum threshold.
4. Checkout errors increase sharply.
5. A landing page gets paid traffic but no conversions.
6. A tracked event disappears after a deploy.
7. A feature event spikes unexpectedly.
8. Revenue drops after a campaign or experiment launch.

Weak alert candidates:

1. Metrics that naturally move up and down with no action needed.
2. Vanity metrics nobody owns.
3. Dashboards that are interesting but not operational.
4. Very low-volume events where every change looks dramatic.

An alert should answer one practical question: “If this fires, who does what next?”

If there is no owner or response plan, the alert will become noise.

What You Need Before You Start

Before creating the alert, confirm:

Requirement	What to check	Example
Event name	The event you want to monitor exists	$pageview, form_submitted, checkout_completed
Volume	The event happens often enough to alert on	Daily signup volume, hourly pageviews
Insight	The metric is already visible in a saved insight	Trend or funnel insight
Threshold	You know what normal and abnormal look like	Less than 10 signups per day
Destination	You know where the alert should go	Slack channel or webhook
Owner	Someone is responsible for responding	Growth, marketing, product, engineering
Exclusions	Internal/test traffic is filtered where needed	Exclude team users and staging domains

The most important part is the threshold. A poorly chosen threshold creates either missed issues or constant false alarms.

Step 1: Choose the Website Metric to Monitor

Start with a metric that affects business outcomes.

In a marketing website, common alert metrics include:

$pageview
cta_clicked
form_started
form_submitted
demo_booked
lead_created

For ecommerce, common alert metrics include:

product_viewed
add_to_cart
checkout_started
checkout_completed
purchase
payment_failed

For SaaS or product-led growth, common alert metrics include:

user_signed_up
onboarding_started
onboarding_completed
trial_started
subscription_started
feature_used

Choose one metric for the first alert. It is better to create one reliable alert than ten noisy ones.

Step 2: Build the Insight in PostHog

In PostHog:

1. Go to Product analytics.
2. Create a new insight.
3. Choose the insight type, usually Trends for event volume or Funnels for conversion flow.
4. Select the event you want to monitor.
5. Add filters for page URL, domain, campaign, user segment, or environment if needed.
6. Choose the date range and interval.
7. Save the insight with a clear name.

For example, to monitor website traffic:

Insight type: Trends
Event: $pageview
Filter: Current URL contains example.com
Interval: Daily
Aggregation: Total count

For lead form monitoring:

Insight type: Trends
Event: form_submitted
Filter: Page URL contains /contact
Interval: Daily
Aggregation: Total count

To monitor funnel progression:

Insight type: Funnels
Step 1: $pageview on /pricing
Step 2: cta_clicked
Step 3: form_submitted

[Screenshot: PostHog Trends insight for daily website pageviews]

[Screenshot: PostHog Funnel insight for pricing page to form submission]

Step 3: Clean the Insight Before Adding an Alert

Do not create alerts on messy data.

Before adding the alert, check:

1. Internal users are excluded.
2. Staging domains are excluded.
3. Test events are excluded.
4. Bot traffic is not dominating the metric.
5. The selected interval matches the response time you need.
6. The metric has enough historical data to understand normal behavior.

For example, if your website gets most traffic Monday through Friday, a weekend drop might be normal. If your alert fires every Saturday, the threshold is not useful.

If you monitor a low-volume event, such as enterprise demo bookings, hourly alerts may be too noisy. Daily or weekly alerts may be more appropriate.

Step 4: Create the Alert

Once the insight is saved and clean, create the alert from the insight.

In PostHog:

1. Open the saved insight.
2. Click the alert or subscription option.
3. Choose Create alert.
4. Select the metric series if the insight has more than one.
5. Choose the condition.
6. Set the threshold or anomaly detection behavior.
7. Choose how often PostHog should evaluate the alert.
8. Select the notification destination.
9. Save the alert.

PostHog supports alerts from insights and can send notifications to destinations such as Slack or webhook endpoints, depending on your workspace setup.

[Screenshot: PostHog alert creation panel for a saved insight]

Step 5: Choose the Right Alert Condition

The alert condition should match the type of issue you want to catch.

Use a threshold alert for known minimums or maximums

Use a threshold when you know the number that should trigger action.

Examples:

Pageviews are below 1,000 per day
Signup submissions are below 5 per day
Checkout errors are above 20 per hour
Purchases are below 10 per day

Thresholds are simple and easy to explain. They are best when the metric has a clear operational boundary.

Use an anomaly alert for unusual changes

Use anomaly detection when the metric has a regular pattern and you want PostHog to detect unusual movement.

Examples:

Traffic is unusually low compared with recent history
Form submissions are unusually high after a spam attack
Checkout failures spike above normal behavior
Product usage drops after a release

Anomaly alerts are useful when normal volume changes by day, week, season, or campaign.

Use comparison logic for campaign or launch monitoring

If your insight compares periods or variants, use an alert only when the comparison has a clear meaning.

Example:

Landing page conversion rate is 30% lower than the previous 7-day average

This is useful after launches, but it needs enough data. Small samples can create false panic.

Step 6: Send the Alert to the Right Place

An alert should go where the responsible team already works.

Common destinations:

Destination	Best for
Slack channel	Marketing, growth, product, or engineering team alerts
Webhook	Sending alerts into custom workflows, incident tools, or automation
Email	Lightweight alerts for small teams or low-frequency checks

For Slack, choose a channel that matches the alert owner.

Examples:

#growth-alerts
#website-monitoring
#analytics-alerts
#engineering-oncall

Avoid sending every alert to a busy general channel. The alert will get ignored.

[Screenshot: PostHog alert destination configured for a Slack channel]

Step 7: Add Context to the Alert Name

Use a name that tells the team what happened and what metric is affected.

Good alert names:

Website pageviews below daily baseline
Demo form submissions dropped
Checkout completed event missing
Payment failures above hourly threshold
Pricing page funnel conversion anomaly

Weak alert names:

Alert 1
Website alert
Important
PostHog problem

If PostHog allows a description or message in your alert destination, include:

1. What metric is watched.
2. What threshold or anomaly condition fired.
3. Where to inspect the source insight.
4. Who owns the first check.
5. What the first troubleshooting step should be.

Example alert message:

Demo form submissions are below the daily threshold.
Check the PostHog insight, then test the form on /contact and confirm the form_submitted event fires.
Owner: Growth

Step 8: Test the Alert

Testing depends on the alert type and volume, but you should still validate the setup.

Check:

1. The alert is attached to the correct insight.
2. The condition is using the correct metric series.
3. The destination receives a test or real notification.
4. The linked insight opens for the team.
5. The alert does not include internal or staging data.
6. The threshold matches the intended period.

For critical conversion events, do a manual event test:

1. Open the website in a clean browser session.
2. Complete the target action, such as submitting the form.
3. Confirm the event appears in PostHog Activity.
4. Confirm the saved insight updates after ingestion.
5. Confirm the alert condition would make sense if the event stopped firing.

[Screenshot: PostHog Activity view showing a test form_submitted event]

Step 9: Monitor Alert Quality for the First Week

The first week tells you whether the alert is useful.

Review:

1. Did the alert fire when something real happened?
2. Did it fire too often?
3. Did it miss an issue?
4. Did the right person see it?
5. Did the message contain enough context?
6. Did the threshold need weekday/weekend adjustment?
7. Was the interval too short or too long?

If an alert fires repeatedly and nobody acts, change it or remove it. A noisy alert trains the team to ignore PostHog.

Practical Alert Examples

Website traffic drop alert

Use this when paid traffic, SEO, or campaign landing pages matter.

Insight type: Trends
Event: $pageview
Filter: URL contains your primary domain
Interval: Daily
Condition: Below expected baseline or anomaly detected
Destination: #website-monitoring

What to check when it fires:

1. Analytics tracking script loaded correctly.
2. Website is live.
3. Recent deploy did not break tracking.
4. Paid campaigns are still active.
5. SEO or referral traffic did not unexpectedly drop.

Lead form drop alert

Use this when forms are a key conversion point.

Insight type: Trends
Event: form_submitted
Filter: Page URL contains /contact or /demo
Interval: Daily
Condition: Below minimum threshold
Destination: #growth-alerts

What to check when it fires:

1. Form still submits successfully.
2. Tracking event still fires.
3. CRM or email integration still receives the lead.
4. Spam protection is not blocking real submissions.
5. Paid traffic is still reaching the page.

Checkout completion alert

Use this for ecommerce and revenue-sensitive funnels.

Insight type: Trends
Event: checkout_completed
Interval: Hourly or daily
Condition: Below threshold or anomaly detected
Destination: #revenue-alerts

What to check when it fires:

1. Payment provider is working.
2. Checkout page is reachable.
3. Purchase event still fires.
4. Recent checkout changes did not break tracking.
5. Product availability, shipping, or discount rules did not change unexpectedly.

Error spike alert

Use this when frontend or backend errors affect conversion.

Insight type: Trends
Event: error_captured or custom error event
Interval: Hourly
Condition: Above threshold
Destination: #engineering-oncall

What to check when it fires:

1. Error details and affected URLs.
2. Browser, device, and operating system patterns.
3. Recent releases.
4. Conversion impact.
5. Whether the error affects all users or a segment.

Common Mistakes to Avoid

Creating alerts before cleaning event data

If your insight includes internal traffic, staging events, test purchases, or duplicate events, the alert will inherit those problems.

Monitoring too many metrics at once

Start with critical business events. Too many alerts create noise and make the useful ones easier to miss.

Using hourly alerts for low-volume events

If an event only happens a few times per week, hourly alerts are likely to be noisy. Use daily or weekly monitoring instead.

Alerting on vanity metrics

Do not alert on metrics that do not trigger action. Alerts should protect traffic, tracking, conversion, revenue, or product reliability.

Sending alerts to the wrong channel

If nobody in the destination owns the metric, the alert will be ignored.

Forgetting seasonality

Traffic and conversions may behave differently by weekday, weekend, campaign cycle, or holiday. Use anomaly detection or smarter thresholds when a fixed number is too blunt.

Not documenting what to do when the alert fires

Every important alert needs a response path. Otherwise the notification creates anxiety instead of action.

Troubleshooting a PostHog Alert

The alert never fires

Check that the insight is saved, the alert is active, the threshold can actually be reached, and the selected series is correct.

The alert fires too often

Raise the threshold, increase the interval, use anomaly detection, add filters, or remove low-value metrics.

The Slack message does not arrive

Check the Slack destination setup, channel permissions, PostHog integration status, and whether the alert is using the correct destination.

The alert fires but the data looks wrong

Inspect the underlying events. The issue may be duplicate tracking, missing filters, staging data, internal users, bots, or a changed event name.

The insight updates but the alert does not

Check the alert evaluation frequency and whether the condition is based on a different series, breakdown, or date interval than the chart you are viewing.

Recommended Alert Naming Convention

Use a simple naming pattern:

[Area] - [Metric] - [Condition]

Examples:

Website - Daily pageviews - Below baseline
Lead gen - Demo submissions - Dropped below 5/day
Checkout - Completed purchases - Anomaly detected
Errors - Frontend exceptions - Above hourly threshold

This makes alerts easier to scan in PostHog and in Slack.

Alert Maintenance Checklist

Review important alerts monthly or after major website changes.

Check:

1. The event still exists.
2. The insight still matches the business question.
3. The threshold still reflects normal volume.
4. Internal and staging filters still work.
5. The notification channel is still correct.
6. The owner is still responsible.
7. The alert has not become noisy.
8. The response instructions are still accurate.

Also review alerts after:

1. Website redesigns.
2. Tracking script changes.
3. Checkout or form changes.
4. Campaign launches.
5. Domain or URL structure changes.
6. PostHog event taxonomy updates.

Why PostHog Alerts Matter for CRO

CRO depends on clean, timely data.

If your conversion event breaks, your experiment results become unreliable. If a landing page gets traffic but the form fails, the cost is immediate. When checkout errors spike after a theme update, revenue can drop before anyone opens a dashboard.

PostHog alerts help protect the parts of your website that matter most:

1. Acquisition traffic.
2. Lead capture.
3. Checkout performance.
4. Signup flow health.
5. Experiment measurement.
6. Tracking reliability.
7. Revenue-impacting events.

The best alerts are not just analytics notifications. They are small operational safeguards for your growth system.

Frequently asked questions

learn more:

Discover how to run A/B tests on WordPress and Shopify to optimize your website performance.

External References

1. PostHog Alerts documentation
2. PostHog Trends documentation
3. PostHog Funnels documentation