Set up log alerts

Log alerts notify you when the volume of logs matching specific filters crosses a threshold. Use them to catch spikes in errors, drops in expected traffic, or unusual patterns across your services.

Alerts are checked every 5 minutes and can be configured with noise-reduction settings to avoid false positives from brief, one-off spikes.

Create an alert

You can manage alerts from the Alerts tab in the Logs section, or from Settings > Environment > Logs > Alerting.

1. Click New alert.
2. Give your alert a descriptive name (e.g. "API 5xx errors").
3. Configure your filters, threshold rules, and notification destinations. Optionally adjust advanced options to reduce noise.
4. (Optional) Use the Simulate panel to preview which logs would have matched your filters and threshold against recent historical data before saving.
5. Click Create alert.

Configure filters

Every alert requires at least one filter — saving without one returns the error "At least one filter is required". Filters determine which logs are counted against your threshold. You can combine multiple filter types.

Severity

Filter by log severity levels (e.g. ERROR, WARN, INFO). Select one or more levels from the dropdown.

Service

Filter by service name. Select one or more services from the dropdown to scope the alert to specific parts of your infrastructure.

Attributes

Filter by log attributes, resource attributes, or other log properties. Use the attribute search to find and add filters. These work the same way as filters in the log search view.

Set threshold rules

Threshold rules define the condition that triggers the alert. Configure:

• Operator – whether the log count must go above or below the threshold (default: above)
• Count – the number of matching logs that triggers the alert (default: 100)
• Window – the time window to check, one of 5, 10, 15, 30, or 60 minutes (default: 10 minutes)

For example, "alert if count goes above 100 in the last 10 minutes" fires when more than 100 matching logs are observed in a rolling 10-minute window.

Configure notifications

An alert without a destination has nowhere to send notifications. Add at least one of:

• Slack – pick a connected Slack workspace and channel.
• Microsoft Teams – provide a Microsoft Teams webhook URL (from a Power Automate Workflows connector).
• Webhook – provide a URL to receive an HTTP POST when the alert fires.

Destinations are delivered through hog functions under the hood, so they reuse the same infrastructure as other PostHog destinations. The Notifications column in the alert list shows a struck-through bell when no destinations are configured.

Webhook payloads

PostHog sends an HTTP POST with a JSON body in the Alertmanager webhook format, so incident and on-call tools that accept Alertmanager webhooks can read it without a custom parser. The webhook URL must use https.

• Headers:
  • Content-Type: application/json
  • X-PostHog-Webhook-Version: 2 is the payload version. New fields may be added to the body without changing it, so ignore unknown fields rather than rejecting the payload. A breaking change would ship under a new version.

Each request carries one alert. The posthog_event_kind label tells you what happened. Route on it:

Alertmanager has only the firing and resolved statuses, so errored and broken are sent as firing. They use their own fingerprint, so a later resolved for the condition doesn't close them.

Labels:

• alertname is the alert's name.
• posthog_configuration_id identifies the alert.
• posthog_source_kind is logs.
• posthog_event_kind is one of the values in the table above.
• An alert that groups by service or severity adds a service_name or severity_text label with the group's value.

Annotations:

• summary is a one-line headline, such as "Log alert 'Checkout errors' is firing".
• description lists the details, such as Threshold breached: 132 logs in 10m (threshold: above 100).
• value is the value the check measured, when there is one.
• error is the reason a check couldn't run, on errored and broken payloads.

startsAt is when the alert started firing, and endsAt is 0001-01-01T00:00:00Z until it resolves. generatorURL links to the alert in PostHog. fingerprint is the same for the firing and resolved payloads of one alert, or of one group in a grouped alert, so you can use it to match them.

A firing payload looks like this:

{
  "version": "4",
  "groupKey": "0192f3a4-...:...",
  "truncatedAlerts": 0,
  "status": "firing",
  "receiver": "posthog",
  "groupLabels": {
    "alertname": "Checkout errors",
    "posthog_configuration_id": "0192f3a4-...",
    "posthog_source_kind": "logs"
  },
  "commonLabels": {
    "service_name": "checkout",
    "alertname": "Checkout errors",
    "posthog_configuration_id": "0192f3a4-...",
    "posthog_source_kind": "logs",
    "posthog_event_kind": "firing"
  },
  "commonAnnotations": { "summary": "Log alert 'Checkout errors' is firing", "...": "..." },
  "externalURL": "https://us.posthog.com",
  "alerts": [
    {
      "status": "firing",
      "labels": { "...": "the same labels as commonLabels" },
      "annotations": { "...": "the same annotations as commonAnnotations" },
      "startsAt": "2026-11-05T12:00:00Z",
      "endsAt": "0001-01-01T00:00:00Z",
      "generatorURL": "https://us.posthog.com/project/1/...",
      "fingerprint": "3f1c9a0b2d4e6f78"
    }
  ]
}

Projects that had a webhook on logs or insight alerts by November 6, 2026 keep receiving the earlier payload, sent with X-PostHog-Webhook-Version: 1. Check the header to tell the two formats apart.

Signals for the self-driving inbox

When an alert enters the Firing or Broken state, it automatically emits a signal to the self-driving inbox. The signal includes the alert name, threshold, observed count, window, filters, and a direct link to the matching logs. This enables the inbox research agent to correlate the alert with your codebase and investigate the root cause.

Only Firing and Broken state changes emit signals. Resolving and Errored states don't generate signals.

Advanced options

Reduce noise

By default, an alert fires as soon as a single check breaches the threshold. To prevent notifications from brief spikes, require multiple consecutive checks to match before firing.

Configure this with two values:

• Datapoints to alarm – how many checks must breach the threshold (default: 1)
• Evaluation periods – the total number of recent checks to consider (default: 1, max: 10)

For example, setting "3 of 5 checks must match to fire" means the threshold must be breached in at least three of the last five check windows before the alert triggers.

The alert auto-resolves once the condition is no longer met.

Notification cooldown

You can set a cooldown period (in minutes) to limit how often an alert sends firing and resolve notifications. Set it to 0 for no minimum. The default is 0.

An alert sends one notification when it starts firing and one when it resolves. It doesn't notify again unless it resolves and then fires again, even if new matching logs arrive while it's firing.

The cooldown sets the minimum time between an alert's firing and resolve notifications. PostHog doesn't send them during the cooldown, which cuts noise from an alert that keeps resolving and firing again.

Manage alerts

The alert list shows a table of all your alerts:

Alert states

Edit an alert

Open the ⋯ menu and select Edit. Update any fields and click Save. Clicking the alert name opens the detail view rather than the edit modal.

Snooze an alert

Open the ⋯ menu and select Snooze, then pick a duration: 30 minutes, 1 hour, 4 hours, or 24 hours. The alert won't fire until the snooze expires. To clear it early, open the menu again and choose Unsnooze.

Reset a broken alert

If an alert errors on 5 consecutive checks, it enters the Broken state and stops evaluating. Open the ⋯ menu and select Reset alert to clear the failure count and resume checks.

View history

Open the ⋯ menu and select View history to see the alert's state transitions, errors, and changes such as enabling, snoozing, editing the threshold, or resetting it. History leaves out checks that neither change the alert's state nor hit an error.

Delete an alert

Open the ⋯ menu and select Delete. Confirm in the dialog. This action can't be undone.