AutoGineer
Generated banner for Authoring Error Tracking Alerts
Generated logo for Authoring Error Tracking Alerts

Authoring Error Tracking Alerts

PostHogOfficialPublished by PostHog

  • Skill
  • Workflow
  • Data and AI
  • MIT
  • No issues found
Download ZIP

From the author

Author error tracking alerts that fire when an issue is created, reopened, or starts spiking. Use when the user asks to set up error notifications, route exceptions to Slack/webhook/Linear, or evaluate which error events are worth alerting on. Covers trigger-event selection, integration choice, dedup against existing alerts, and shipping with the canonical message body shape.
— the description by PostHog

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured workflow for setting up error tracking notifications within a project. It focuses on routing error lifecycle events—specifically issue creation, reopening, and spiking—to external destinations like Slack, webhooks, or issue trackers. The process emphasizes preventing alert fatigue through proper deduplication, selecting the appropriate trigger event based on user intent, and using canonical message templates to ensure consistency with in-product alerts.

What it does

  • Lists existing error tracking alerts to prevent duplicate configurations.
  • Retrieves available integration channels for Slack, webhooks, and issue trackers.
  • Creates new error tracking alerts using standardized message templates.
  • Supports per-issue scoping using event property filters.
  • Provides a consistent naming convention for easy management of agent-created alerts.
  • Verifies and summarizes the configuration details for the user.

When to use it

  • When a user requests notifications for new errors or exceptions.
  • When a user wants to be alerted if a previously resolved issue recurs.
  • When a user needs to monitor for abnormal spikes in error volume.
  • When setting up a new project and establishing a baseline for error monitoring.

Advantages

  • Reduces alert fatigue by guiding users toward the most signal-dense trigger events.
  • Ensures consistency with native UI alerts by using canonical block templates.
  • Prevents redundant notifications through mandatory deduplication checks.
  • Supports flexible routing to various platforms including Slack, Linear, and webhooks.

Usage examples

“Set up an alert to notify our #oncall channel whenever an error issue starts spiking.”
The agent will list existing alerts, confirm the #oncall channel ID, and create a spiking alert using the canonical template.
“I want to know if the 'DatabaseConnectionError' issue comes back after we fix it.”
The agent will configure a '$error_tracking_issue_reopened' alert scoped specifically to that issue's fingerprint.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/posthog/authoring-error-tracking-alerts/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip authoring-error-tracking-alerts.zip -d .agents/skills

Documentation by PostHog

Authoring error tracking alerts

Authoring an error tracking alert is a routing problem, not a measurement problem. The trigger events already exist and fire on real conditions in the ingestion pipeline — your job is to pick the right trigger for the user's intent, dedupe against what's already configured, and wire a destination they can actually act on.

When to use this skill

  • The user asks to set up alerts / notifications for errors or exceptions in their project.

  • The user wants a starter set of alerts after enabling error tracking.

  • The user pastes an issue link and asks "notify me when this happens again" — usually _reopened with a per-issue property filter.

When not to use this skill

  • Tuning the spike detector itself (multiplier, window, threshold). That lives behind the spike detection config endpoint and is not exposed via MCP today.

  • Investigating an active incident — query the issue / its events directly via posthog:query-error-tracking-issue and posthog:query-error-tracking-issue-events instead of authoring more alerts mid-fire.

  • Configuring volume-threshold alerts (count of $exception events over a window). That's a logs-style alert and is not in scope here — error tracking alerts ride the lifecycle events instead.

Tools

ToolJobWhere it fits
posthog:error-tracking-alerts-listList existing alerts (paginated); dedupe before creating.Step 2 — dedupe.
posthog:integrations-listFind the user's Slack workspace id (filter by kind=slack).Step 3 — pick channel.
posthog:integrations-channels-retrieveList Slack channels for a workspace.Step 3 — pick channel.
posthog:error-tracking-alerts-createCreate the alert (HogFunction with type=internal_destination).Step 4 — ship.
posthog:error-tracking-alerts-partial-updateToggle, rename, or modify an existing alert.When tuning, not authoring.
posthog:error-tracking-alerts-deleteSoft-delete an alert.When the user says "remove".

Trigger events — pick exactly one per alert

There are three lifecycle events. Each has a different "noise vs urgency" trade-off — picking the wrong one is the most common cause of alert fatigue here.

EventFires whenUse when
$error_tracking_issue_createdA brand-new issue first appears.Small projects, or projects where every new error type is genuinely worth a look. Floods large/noisy projects.
$error_tracking_issue_reopenedA previously resolved issue starts emitting again.Catch regressions on issues someone already triaged. The safest "I want to know if this comes back" trigger.
$error_tracking_issue_spikingThe spike detector flags abnormal volume on an issue.Production projects with high baseline volume. Threshold/multiplier is shared across the project — check spike config before using.

If the user is vague ("alert me on errors"), default to _spiking. It's the most signal-dense trigger and the least likely to cause alert fatigue. Confirm explicitly before proceeding.

Workflow

1. Confirm intent

You need three things from the user before creating anything:

  • Which trigger event. If unspecified, recommend _spiking and ask for confirmation. Do not silently pick one.

  • Which channel. Slack channel name, webhook URL, Linear team, etc. Never hardcode a production channel. If the user says "the dev channel", ask for the exact channel id or name.

  • Which scope. All issues (most common), or scoped to a specific issue / exception type / assignee.

2. Dedupe against existing alerts

Scan every destination before you decide. The endpoint is paginated and defaults to 100 rows per page, so a single default call misses older alerts on a project with hundreds of destinations.

Call posthog:error-tracking-alerts-list with type: ["internal_destination"] and limit: 1000. If the response still carries a non-null next, keep paging with offset until next is null. Then filter the collected rows client-side by filters.events[].id and by any per-issue scope in filters.properties.

The list response carries no inputs, so it does not tell you which channel or URL a row delivers to. Read the destination off name and description instead — the naming convention below puts the channel in the name. When a row matches on event and scope but its name does not say where it delivers, do not guess: show the user the matching names and ask whether one of them is the alert they mean.

  • If an alert exists for the same event delivering to the same channel with the same scope, stop. Tell the user it already exists and ask whether they want to change anything (in which case use error-tracking-alerts-partial-update) or skip.

  • Multiple alerts on the same event for the same channel produce duplicate Slack messages — the user almost never wants this.

  • Multiple alerts on the same event for different channels (e.g. one for #oncall, one for the oncall webhook) is fine and sometimes intentional. Confirm.

  • Multiple alerts on the same event and channel but different scopes (e.g. two _reopened alerts each pinned to a different $exception_issue_id) are not duplicates. Confirm before adding. Note that a scoped alert and an all-issues alert to the same channel both fire on the scoped issue.

PostHog's "alerts configured" recommendation only inspects filters.events — adding per-issue filters.properties does not affect the status the alerts banner reports.

3. Pick the integration

For Slack:

  1. posthog:integrations-list with kind=slack → pick the integration id (an integer).

  2. posthog:integrations-channels-retrieve with that id → pick the channel id (e.g. C0123ABC). Channel names like "#oncall" are accepted but channel ids are preferred — they survive renames.

For webhook: the user supplies a single https:// URL. Refuse http:// URLs.

For Linear / GitHub / GitLab: confirm the integration is connected via posthog:integrations-list first, then ask the user which project / repository / team to file issues into.

4. Create the alert

Call posthog:error-tracking-alerts-create with:

{
  "type": "internal_destination",
  "template_id": "template-slack",
  "name": "<short, channel-attributed name>",
  "enabled": true,
  "filters": {
    "events": [{ "id": "$error_tracking_issue_created", "type": "events" }]
  },
  "inputs": {
    "slack_workspace": { "value": <slack_integration_id_int> },
    "channel": { "value": "<channel_id>" },
    "text": { "value": "..." },
    "blocks": { "value": [...] }
  }
}

The canonical Slack blocks payload for each event lives in references/block-templates.md. Copy the matching block verbatim — it matches the in-product alert wizard, so agent-created alerts look identical to UI-created ones.

For per-issue scoping — created / reopened only, spiking events carry no exception properties — add to filters:

"properties": [
  { "key": "$exception_issue_id", "value": "<issue_uuid>", "operator": "exact", "type": "event" }
]

Other useful property filters: $exception_types (exception class names, an array), name (issue title). See references/event-triggers.md for the full property surface per event.

5. Verify

Echo the alert back to the user with: name, trigger event (human-readable), destination, and a one-line preview of the message body. Do not echo Slack workspace ids or webhook URLs — those are sensitive. Tell the user how to disable: "you can pause this alert by setting enabled: false via error-tracking-alerts-partial-update or by toggling it in the destinations UI."

Naming convention

Use <trigger> · <channel> (auto) so the user can scan their alert list and spot agent-created entries. Examples:

  • Issue spiking · #oncall (auto)

  • Issue reopened · #regressions-webhook (auto)

  • Issue created · Linear/Eng (auto)

Do not use the issue title in the name — alerts can match many issues, and the title becomes stale once the issue evolves.

Token-economy rules

  • One complete posthog:error-tracking-alerts-list scan up front, not per candidate. The scan is complete only when next is null — page through it once and reuse the collected rows for every candidate.

  • Reuse a single integration lookup for multiple alerts going to the same workspace.

  • Confirm the channel / URL with the user before creating each alert. Never batch-create alerts to a destination the user has not explicitly named.

  • Cap iteration at 1 round per alert. If the user wants three alerts, that's three create calls — not three create calls per alert.

Output

Report what you did, in this shape:

  • For each shipped alert: name, trigger event, destination (channel name or webhook host — never the full URL), enabled state.

  • For each skipped alert: trigger + channel + why (already exists, user declined, missing integration).

  • Anything the user should do next: enable the spike detection config (if they picked _spiking and the detector hasn't been turned on), wire up source maps (so the alert's stack trace links resolve), or tune the alert filters after watching it for a day.

Related skills

  • triaging-error-issues — work out which issues actually matter before wiring alerts for them

  • investigating-error-issue — deep-dive an issue an alert fired for

  • authoring-log-alerts — the same alerting job, but for log lines instead of exceptions

Files

references/block-templates.md

Block-kit and message body templates

Canonical message body shapes for each event × integration. Copy verbatim — these match the in-product alert wizard, so agent-created and UI-created alerts produce identical notifications.

The three placeholders inside inputs that you must fill at create time are:

  • slack_workspace.value — the integer integration id from posthog:integrations-list (Slack only).

  • channel.value — Slack channel id like C0123ABC (preferred) or #name.

  • url.value — webhook destination URL (webhook integrations only).

Everything else in the templates below is a HogQL template expression that will be evaluated at fire time against the live event — leave the curly-braced segments as-is.

Contents

  • $error_tracking_issue_created

  • $error_tracking_issue_reopened

  • $error_tracking_issue_spiking

$error_tracking_issue_created

Slack — template-slack
{
  "type": "internal_destination",
  "template_id": "template-slack",
  "name": "Issue created · #<channel> (auto)",
  "enabled": true,
  "filters": {
    "events": [{ "id": "$error_tracking_issue_created", "type": "events" }]
  },
  "inputs": {
    "slack_workspace": { "value": <slack_integration_id_int> },
    "channel": { "value": "<channel_id>" },
    "text": { "value": "New issue created: {event.properties.name}" },
    "blocks": {
      "value": [
        { "type": "header", "text": { "type": "plain_text", "text": "🔴 {event.properties.name}" } },
        { "type": "section", "text": { "type": "plain_text", "text": "New issue created" } },
        { "type": "section", "text": { "type": "mrkdwn", "text": "```{substring(event.properties.description, 1, 150)}```" } },
        {
          "type": "context",
          "elements": [
            { "type": "plain_text", "text": "Status: {event.properties.status}" },
            { "type": "mrkdwn", "text": "Project: <{project.url}|{project.name}>" },
            { "type": "mrkdwn", "text": "Alert: <{source.url}|{source.name}>" }
          ]
        },
        { "type": "divider" },
        {
          "type": "actions",
          "elements": [
            {
              "type": "button",
              "text": { "type": "plain_text", "text": "View Issue" },
              "url": "{project.url}/error-tracking/fingerprint/{encodeURLComponent(event.properties.fingerprint)}?timestamp={event.properties.exception_timestamp}&utm_source=alert&utm_campaign=error_tracking_alert&utm_medium=slack"
            }
          ]
        }
      ]
    }
  }
}
Webhook — template-webhook
{
  "type": "internal_destination",
  "template_id": "template-webhook",
  "name": "Issue created · <host> (auto)",
  "enabled": true,
  "filters": {
    "events": [{ "id": "$error_tracking_issue_created", "type": "events" }]
  },
  "inputs": {
    "url": { "value": "https://example.com/hooks/posthog-error-tracking" }
  }
}
Discord — template-discord
"inputs": {
  "content": {
    "value": "**🔴 {event.properties.name} created:** {event.properties.description}\n\n[View in PostHog]({project.url}/error-tracking/fingerprint/{encodeURLComponent(event.properties.fingerprint)}?timestamp={event.properties.exception_timestamp}&utm_source=alert&utm_campaign=error_tracking_alert&utm_medium=discord)"
  }
}
Microsoft Teams — template-microsoft-teams
"inputs": {
  "text": {
    "value": "**🔴 {event.properties.name} created:** {event.properties.description} (View in [PostHog]({project.url}/error-tracking/fingerprint/{encodeURLComponent(event.properties.fingerprint)}?timestamp={event.properties.exception_timestamp}&utm_source=alert&utm_campaign=error_tracking_alert&utm_medium=microsoft_teams))"
  }
}
Linear / GitHub / GitLab

These integrations file a tracking issue rather than post a message. Use the same inputs shape across all three:

"inputs": {
  "title": { "value": "{substring(replaceAll(notEmpty(event.properties.description) ? concat(event.properties.name, ': ', event.properties.description) : event.properties.name, '\\n', ' '), 1, 120)}" },
  "description": { "value": "{notEmpty(event.properties.description) ? concat('```\\n', replaceAll(event.properties.description, '`', '\\''), '\\n```') : ''}\n{notEmpty(trim(concat(event.properties.$browser, ' ', event.properties.$browser_version))) ? concat('\\n- Browser: ', concat('`', replaceAll(replaceAll(replaceAll(trim(concat(event.properties.$browser, ' ', event.properties.$browser_version)), '`', '\\''), '\\n', ' '), '\\r', ' '), '`')) : ''}{notEmpty(trim(concat(event.properties.$os, ' ', event.properties.$os_version))) ? concat('\\n- OS: ', concat('`', replaceAll(replaceAll(replaceAll(trim(concat(event.properties.$os, ' ', event.properties.$os_version)), '`', '\\''), '\\n', ' '), '\\r', ' '), '`')) : ''}{notEmpty(event.properties.$exception_release.version) ? concat('\\n- Release: ', concat('`', replaceAll(replaceAll(replaceAll(event.properties.$exception_release.version, '`', '\\''), '\\n', ' '), '\\r', ' '), '`')) : ''}{notEmpty(event.properties.$session_id) and (empty(event.properties.$recording_status) or has(['active', 'sampled', 'buffering'], event.properties.$recording_status)) ? concat('\\n- Session replay: ', concat(project.url, '/replay/', encodeURLComponent(event.properties.$session_id))) : ''}" },
  "posthog_issue_id": { "value": "{event.distinct_id}" },
  "posthog_issue_url": { "value": "{project.url}/error-tracking/fingerprint/{encodeURLComponent(event.properties.fingerprint)}?timestamp={event.properties.exception_timestamp}&utm_source=alert&utm_campaign=error_tracking_alert&utm_medium=linear" }
}

The title reads as the exception type and message, for example RangeError: Invalid Date, on one line, cut at 120 characters. The description is the message, then a Markdown list of the browser, OS, release and a session replay link. The destination code then adds up to 5 resolved in-app stack frames as a code block, so the inputs do not carry the trace. Each frame shows only the file name, the line and the function name. A file name that does not look like a source file, a function name with characters outside an identifier set, or any name that holds a UUID or looks like a key or token, becomes [redacted]. The message sits in a code block and the browser, OS and release values sit in inline code, so client-sent text cannot render links, images or @mentions. Do not add the page URL, request data, local variables or source lines to these inputs. Trackers sit outside PostHog's access controls and a repository can be public, so these values can expose tokens and user data. Each list line is left out when the event has no value for it, and the replay line is left out when replay was not recording. Keep the list form: GitLab joins plain consecutive lines into one paragraph. _spiking events carry no exception properties, so on them only the message would render.

Set utm_medium to the destination (linear, github, gitlab). posthog_issue_url is the merge-stable deep link embedded in the external issue; when omitted, the destination falls back to building a link from posthog_issue_id.

$error_tracking_issue_reopened

Slack — template-slack

Same as _created, with the header swapped to 🔄 and the section text to "Issue reopened":

"blocks": {
  "value": [
    { "type": "header", "text": { "type": "plain_text", "text": "🔄 {event.properties.name}" } },
    { "type": "section", "text": { "type": "plain_text", "text": "Issue reopened" } },
    { "type": "section", "text": { "type": "mrkdwn", "text": "```{substring(event.properties.description, 1, 150)}```" } },
    {
      "type": "context",
      "elements": [
        { "type": "plain_text", "text": "Status: {event.properties.status}" },
        { "type": "mrkdwn", "text": "Project: <{project.url}|{project.name}>" },
        { "type": "mrkdwn", "text": "Alert: <{source.url}|{source.name}>" }
      ]
    },
    { "type": "divider" },
    {
      "type": "actions",
      "elements": [
        {
          "type": "button",
          "text": { "type": "plain_text", "text": "View Issue" },
          "url": "{project.url}/error-tracking/fingerprint/{encodeURLComponent(event.properties.fingerprint)}?timestamp={event.properties.exception_timestamp}&utm_source=alert&utm_campaign=error_tracking_alert&utm_medium=slack"
        }
      ]
    }
  ]
},
"text": { "value": "Issue reopened: {event.properties.name}" }
Discord / Microsoft Teams

Use the same shape as _created, swap 🔴 → 🔄 and "created" → "reopened" in the text body.

$error_tracking_issue_spiking

Slack — template-slack
"blocks": {
  "value": [
    { "type": "header", "text": { "type": "plain_text", "text": "📈 Issue spiking" } },
    { "type": "section", "text": { "type": "mrkdwn", "text": "```{event.properties.name}: {substring(event.properties.description, 1, 1000)}```" } },
    {
      "type": "context",
      "elements": [
        {
          "type": "plain_text",
          "text": "Exceptions in last 5 minutes: {event.properties.current_bucket_value} ({event.properties.computed_baseline > 0 ? concat(round(event.properties.current_bucket_value / event.properties.computed_baseline), 'x over baseline') : 'no baseline yet'})"
        },
        { "type": "mrkdwn", "text": "Project: <{project.url}|{project.name}>" },
        { "type": "mrkdwn", "text": "Alert: <{source.url}|{source.name}>" }
      ]
    },
    { "type": "divider" },
    {
      "type": "actions",
      "elements": [
        {
          "type": "button",
          "text": { "type": "plain_text", "text": "View Issue" },
          "url": "{project.url}/error-tracking/fingerprint/{encodeURLComponent(event.properties.fingerprint)}?timestamp={event.properties.exception_timestamp}&utm_source=alert&utm_campaign=error_tracking_alert&utm_medium=slack"
        }
      ]
    }
  ]
},
"text": { "value": "Issue spiking: {event.properties.name}" }

The computed_baseline > 0 ? ... : 'no baseline yet' guard handles the first spike of the project's lifetime, when the detector has not built up enough history to compute a baseline. Without the guard you end up with 0x over baseline in the message, which is wrong.

Discord — template-discord
"inputs": {
  "content": {
    "value": "**📈 Issue spiking**\n\n```\n{event.properties.name}: {substring(event.properties.description, 1, 1000)}\n```\n**Exceptions in last 5 minutes:** {event.properties.current_bucket_value} ({event.properties.computed_baseline > 0 ? concat(round(event.properties.current_bucket_value / event.properties.computed_baseline), 'x over baseline') : 'no baseline yet'})\n**Project:** [{project.name}]({project.url})\n**Alert:** [{source.name}]({source.url})\n\n[View issue]({project.url}/error-tracking/fingerprint/{encodeURLComponent(event.properties.fingerprint)}?timestamp={event.properties.exception_timestamp}&utm_source=alert&utm_campaign=error_tracking_alert&utm_medium=discord)"
  }
}
Microsoft Teams — template-microsoft-teams
"inputs": {
  "text": {
    "value": "**📈 Issue spiking: {event.properties.name}:** {event.properties.description}\n**Exceptions in last 5 minutes:** {event.properties.current_bucket_value} ({event.properties.computed_baseline > 0 ? concat(round(event.properties.current_bucket_value / event.properties.computed_baseline), 'x over baseline') : 'no baseline yet'}) (View in [PostHog]({project.url}/error-tracking/fingerprint/{encodeURLComponent(event.properties.fingerprint)}?timestamp={event.properties.exception_timestamp}&utm_source=alert&utm_campaign=error_tracking_alert&utm_medium=microsoft_teams))"
  }
}

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
PostHog
Publisher
PostHog (Official)
Source
PostHog/skills · skills/omnibus/authoring-error-tracking-alerts · commit a5d30e7
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by PostHog.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download authoring-error-tracking-alerts.zip