Operations | Monitoring | ITSM | DevOps | Cloud

Sentry + Github Copilot Agents

Seer, Sentry's AI debugger, analyzes your issues and finds the root cause. Now you can pass that analysis directly to a GitHub Copilot agent which picks up the context, generates a fix, and opens a pull request. The agent session and PR both live on GitHub, with a link back in Sentry for easy access. This video walks through how the integration works and how to set it up in just a couple steps.

Next.js already traces your requests. Here's how to export them with OpenTelemetry.

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.

Better, faster, less wrong: Enhancing issue grouping

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.

Catch visual regressions with Snapshots, now in beta

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.

Works on my machine: how we use AI to reproduce reported bugs

Sentry’s SDK teams maintain and support SDKs for a vast ecosystem of languages and frameworks. See our release registry for a source of truth. We’re currently at 159 published packages across the entire ecosystem. If you use it, we probably support it. All of these SDKs are open source and have their own GitHub repositories that we maintain on a daily basis. And like any other open source project, we get tons of bug reports and issues on these.

Errors, traces, logs, metrics: when to reach for what

When should I reach for a log, a trace, or a metric? I hit that question constantly when I instrument code, and I watch coding agents hit it too. It sounds like it should be obvious. Errors, traces, logs, and metrics are the four kinds of telemetry most apps run on, four tools in one box, and they overlap enough that the honest answer is every developer’s favourite: it depends. You can stuff context into span attributes instead of logging it. You can count log events instead of emitting a metric.