Use Logs in PostHog Desktop
Contents
PostHog Desktop is in beta, so some behaviors may still change.
PostHog Desktop is the surface for driving parallel agents that improve your product. For Logs, it's where you review the Self-driving work that your firing alerts generate, plus the shifts PostHog spots in your logs on its own. You don't browse raw log lines here – that's the web app.
What you can do here
When a log alert starts firing, or breaks and auto-disables, it emits a signal into Self-driving. Related signals get grouped into a report with the logs behind them, and when there's a code fix, a drafted pull request.
In PostHog Desktop you can:
- Open a report to see the alert that triggered it, the matching logs, and any related errors and replays
- Merge the pull request when the fix holds up, or steer the agent when it needs more context
- Take a multi-repo fix over locally and keep going with a full agent
Agents working in PostHog Desktop can also query your logs directly through the MCP server, so a report can be investigated further without you switching tools.
What gets signalled
Alerts only signal on two transitions. Not every state change is worth waking an agent for:
| Transition | Why it's signalled |
|---|---|
| Firing | The threshold was crossed – something is worth investigating now |
| Broken | The alert failed repeatedly and auto-disabled – your monitoring has a hole in it |
Resolving alerts and transient errors are deliberately not signalled, so your Self-driving inbox stays about real problems.
What PostHog finds on its own
Alerts only catch what you thought to alert on. Alongside them, PostHog sweeps your logs for shifts nobody wrote a threshold for:
- New and rate-shifted patterns – a message template that's brand new, or whose rate has moved sharply against the same window last week
- Volume bursts – a service logging far more than it usually does
- Severity shifts – the mix tilting toward error or fatal
- Silent services – a service that was logging and has stopped
These arrive as reports with the services, messages, and time ranges behind them. A log shift is usually an investigation rather than a one-line code change, so these are written up for you to confirm – they don't open a pull request on their own.
Related
- Create the alerts that feed this loop in Set up log alerts.
- Learn how the loop works in the Self-driving docs.
- See what else feeds it in signal sources.
- Investigate the underlying logs in the web app.