Operations | Monitoring | ITSM | DevOps | Cloud

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.

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.

Sentry’s Seer Agent lets you ask any questions about your data in Sentry, dive deep into that data, and fix issues faster. One of its particularly cool abilities is letting you ask questions directly about what you’re looking at in Sentry.

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.

This is a guest post by Dan Mindru, a Frontend Developer and Designer who is also the co-host of the Morning Maker Show. Dan is currently developing a number of applications including PageUI, Clobbr, and CronTool. It feels like with every release, we are walking a tightrope. We need to keep our app lightweight, stable, and performant, all the while depending on APIs that can shift at any moment (without warning, too!).

Remember being excited (or dreading, depending on the stage of your career and the company you worked at) about writing unit tests? Or sweating all the details in your end-to-end and integration tests you were sure covered all the use cases your users would hit? These days a lot of UIs are slowly being replaced by a single input field and an agent that promises to deliver the same value a UI would, but with the elegance and pun-ness of a “Jarvis”.

More code is being written right now than at any point in our industry’s history. A year’s worth of software is now created every month, and most of it is no longer written by people. GitHub COO Kyle Daigle recently said, “There were 1 billion commits in 2025.

Traces are a goldmine of information that can help you, or your AI, find slow pages and fix them. Next.js comes out of the box with support for tracing. Incoming requests, fetch() calls, middleware, and server-side rendering are all wired up and ready to send traces to any OpenTelemetry-compatible backend. The catch is, unless you configure an exporter, you’ll never see those traces.

Sentry’s job is to tell you when your app breaks. To do that, we group individual errors into issues. First by fingerprinting, which lexically matches errors based on their structure, then by an AI fallback: when fingerprinting can’t find a match, an ML model compares the new error’s stacktrace against existing issues and merges it if they’re semantically similar.

Sentry Snapshots diffs screenshots on every commit and blocks the PR if there are any visual changes so you can confirm they’re intentional. Users don’t interact with code, they interact with something they can see and touch. Snapshots gives you a lightweight way to test it. It’s easier than ever to change code. It’s also easier than ever to trade quality for speed. Modern codebases need guardrails to ensure correctness.