Operations | Monitoring | ITSM | DevOps | Cloud

How to structure a log

You’ve decided to step up your logging game and start sending more valuable, structured logs that you can query, aggregate, and use for debugging in production. Go, you! Now, uh, how do you actually write them? We’re not going to spend much time on what you should log. We’ve covered that already, a few times before. What we will be covering is how to actually write those logs, answering questions like: What makes a log structured is not just pairing messages with arbitrary JSON objects.

MongoDB Query Tracing in .NET with Sentry + OTLP

If your.NET app talks to MongoDB, you almost certainly want to be able to measure DB performance so that you can effectively debug any performance issues you might run into. For that, you need to know which database command was running, how long it took, and whether this was a one-off blip or part of a broader pattern. Ideally, you also want to pivot from that trace to related errors and replays without stitching the story together by hand.

Session Replay: Reproducible User Sessions

See what your users see. Don't try and guess what happened, watch it. Session Replay is a feature for Mobile and Web apps on Sentry to record user sessions as reproducible sessions. These are not videos. On web, a session replay contains the entire DOM reconstruction and DevTools. It's exactly like inspecting in Chrome DevTools locally on your machine, but in a real production session.

Sentry + GitHub Copilot: Let Agents Find and Fix Your Errors

Andrea Griffiths is a Senior Developer Advocate at GitHub. She uses Sentry to monitor the Python scripts behind GitHub’s community streams, because when those pipelines fail, nobody knows until users start complaining. GitHub and Sentry built a loop that fixes that. Sentry catches the error, Seer diagnoses it, and Copilot drafts the fix. No one has to be in the middle of it. In this session, Paul Jaffre (Developer Experience at Sentry) breaks down what Seer is, then he and Andrea break a real script live and watch the loop catch it, diagnose it, and open the fix as a pull request.

Sentry Seer, MCP, & Warp Agents: Fixing Sentry Issues Outside of Sentry

This video walks through connecting Sentry's MCP server to a Warp Agent, so instead of an agent starting from a raw error, it starts from Seer's actual root cause diagnosis: the error, the surrounding code, and recent commits. From there, the Warp Agent takes that diagnosis, implements the fix directly in the codebase, and opens a PR, all without leaving Warp.

When and what should I be logging?

This is a follow-up to Sergiy’s post Errors, traces, logs, metrics: when to reach for what. Modern observability platforms, like Sentry, give developers a lot of choice. For a given problem, should you use traces, profiles, metrics, logs? If you take away one thing from this post, I hope it’s this: when in doubt, start by adding a few targeted log lines.