> AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt

# Fix pipeline failures in PostHog Desktop

Canonical URL: https://posthog.com/docs/data-pipelines/surfaces/desktop

## On this page

- [Before you start](#before-you-start)
- [How a delivery problem becomes a report](#how-a-delivery-problem-becomes-a-report)
- [Two ways a report gets resolved](#two-ways-a-report-gets-resolved)
- [What you can do here](#what-you-can-do-here)
- [Related](#related)

**Open beta**

PostHog Desktop is in beta. This page is a work in progress.

[PostHog Desktop](https://posthog.com/docs/posthog-desktop.md) is where you review the [Self-driving](https://posthog.com/docs/self-driving.md) work that data pipelines generates. Pipeline failures are quiet – events keep ingesting and your dashboards stay green while a destination silently stops delivering – so a [scout](https://posthog.com/docs/self-driving/scouts.md) watches delivery for you and files what it finds as a report.

## Before you start

1.  **Set up a pipeline** – [create a source, destination, or transformation](https://posthog.com/docs/data-pipelines/start-here.md) so there's something to manage.
2.  **Install PostHog Desktop** – [download the app](https://posthog.com/docs/posthog-desktop/download-posthog-desktop.md) and connect it to your project.

## How a delivery problem becomes a report

A dedicated data pipelines scout runs on a schedule across your destinations, transformations, batch exports, and hog flows. It only cares about the gap between what a pipeline is configured to do and what it's actually doing:

-   **Platform interventions** – PostHog's hog watcher degrading or auto-disabling an enabled function after sustained trouble, so delivery stops without anyone being told. A transformation in this state matters most, because it sits in the ingestion path for every event in the project.
-   **Rising failure share** – an enabled destination whose failure rate steps above its own history, including one that has been failing since the day it was created.
-   **Filter starvation** – a destination that stops firing because the event its filter matches was renamed or stopped. It isn't failing, it's starving.
-   **Stalled or failed batch exports** – a terminal failed run, or a schedule that has fallen behind its own interval. Each missed interval is a permanent data gap until someone backfills it.
-   **Flows failing for real people** – an active hog flow erroring for the recipients it triggers on, usually concentrated in one broken step like a dead webhook or a bad template.

Anything you turned off on purpose is baseline, not a finding: paused exports, disabled functions, and draft or archived flows are operator choices, so the scout leaves them alone.

When a finding clears the bar, the scout files a single report in the [Self-driving inbox](https://posthog.com/docs/self-driving/inbox.md) naming the pipeline, quantifying the contradiction against its own baseline, and dating the onset – with the error class pulled from the function's logs or the flow's failed invocations, and a suggested reviewer.

## Two ways a report gets resolved

Most pipeline problems need a person. A broken remote endpoint, an expired credential, or a watcher intervention isn't something a coding agent can fix, so the report is filed for human review with no repository attached and no pull request.

When the fix is an obvious code change in a function or flow your team owns – a dead webhook URL, a bad template – the report is marked immediately actionable and can auto-start an [implementation run](https://posthog.com/docs/self-driving/inbox/implementation.md). The coding agent works in a sandbox against your connected repo, pushes a branch, and opens a draft pull request. Merging it resolves the report.

## What you can do here

-   Read reports built from real delivery data, with the pipeline, the failure numbers, and the error class in view.
-   Ask questions – start a research task against a report to dig further before acting.
-   Review and edit the draft pull request when the fix is code, then merge it on GitHub.
-   Watch the agent work through the live transcript and the files it changed.

Nothing ships without you. The merge happens on GitHub, so a human is always the last step.

## Related

-   Build and monitor the same pipelines in the [web app](https://posthog.com/docs/data-pipelines/surfaces/web-app.md).
-   Create and debug pipeline functions from your editor over [MCP](https://posthog.com/docs/data-pipelines/surfaces/mcp.md).
-   Diagnose delivery problems yourself with the [troubleshooting guide](https://posthog.com/docs/data-pipelines/troubleshooting.md).
-   Learn how the loop works in the [Self-driving docs](https://posthog.com/docs/self-driving.md).