|
| 1 | +--- |
| 2 | +title: Meet Logs (beta) – more debugging context, all in PostHog |
| 3 | +date: 2025-12-23 |
| 4 | +rootPage: /blog |
| 5 | +sidebar: Blog |
| 6 | +showTitle: true |
| 7 | +hideAnchor: true |
| 8 | +author: |
| 9 | + - sara-miteva |
| 10 | +featuredImage: >- |
| 11 | + https://res.cloudinary.com/dmukukwp6/image/upload/hogs_logs_675386f4fe.jpg |
| 12 | +featuredImageType: full |
| 13 | +category: Product |
| 14 | +tags: |
| 15 | + - Logs |
| 16 | +seo: |
| 17 | + { |
| 18 | + metaTitle: 'Meet Logs (beta) – logs with all the tools you’re already using', |
| 19 | + metaDescription: 'PostHog Logs brings backend logs into the same place as error tracking, session replay, and product analytics, so debugging keeps its context instead of losing it.', |
| 20 | + } |
| 21 | +--- |
| 22 | + |
| 23 | +Every developer's debugging journey ends at the same destination. You can start with an [error](/error-tracking) and get context with a [session replay](/session-replay), but eventually, you'll need logs to see what's actually happening in your system. This progression is so familiar, we barely think of it anymore. |
| 24 | + |
| 25 | +We built [Logs (now in beta)](/docs/logs) for this debugging journey. Not as a new tool to adopt, but as the part of the investigation you were doing anyway. Now you can get the backend context behind your errors and session replays next to your favorite tools in PostHog, without having to leave the platform and open another tab. |
| 26 | + |
| 27 | +## Where context gets messy |
| 28 | + |
| 29 | +When logs live outside the rest of your debugging workflow, they lose their most important attribute: context. You leave the error view, open another tool, recreate the timeframe, match request IDs, and hope you’re looking at the same execution path you were just investigating. |
| 30 | + |
| 31 | +The logs are still accurate and the system is still observable. But the story you’re trying to piece together fragments, and understanding takes longer than it should. At PostHog, we don’t think logs should be something you switch to. They should be already there when you need them. |
| 32 | + |
| 33 | +## Debug faster with Logs next to Session Replays and Error Tracking |
| 34 | + |
| 35 | +With Logs, the debugging journey is continuous. |
| 36 | + |
| 37 | +- When you’re looking at an exception, the logs surrounding that failure are immediately available. |
| 38 | +- When you’re watching a session replay, you can see what the backend was doing during that exact interaction. |
| 39 | +- When you’re investigating a specific user or event, the relevant logs are part of the same view, not a separate search problem. |
| 40 | + |
| 41 | +You're no longer reconstructing the timeline manually. The frontend behavior, backend activity, and failure point stay connected, making understanding faster and less error-prone. |
| 42 | + |
| 43 | +Logs is built on OpenTelemetry, which means you don’t have to change how you log or adopt a proprietary SDK. If you’re already sending logs via OTLP, they work with PostHog out of the box. |
| 44 | + |
| 45 | + |
| 46 | + |
| 47 | +## What's next for Logs and the debugging journey |
| 48 | + |
| 49 | +[Logs is in beta today](https://app.posthog.com/logs), free to use, and focused on tight integration with the rest of the PostHog debugging experience. |
| 50 | + |
| 51 | +Over the coming months, we’re working on deeper connections with Error Tracking and Session Replay, better defaults for viewing logs tied to users and events, and early AI-powered investigation so you can ask questions instead of reading through lines. |
| 52 | + |
| 53 | +The long-term goal is straightforward, even if it’s ambitious: build a logging product where you don’t need to read log lines to understand your system. |
| 54 | + |
| 55 | +[Try it out](https://app.posthog.com/logs) with your existing OpenTelemetry setup and let us know what you think, we’d love to have you help us shape this product. |
0 commit comments