Operations | Monitoring | ITSM | DevOps | Cloud

Bugs don’t announce themselves politely. They crash your checkout flow, break authentication, or slow your API to a crawl—usually right before your CEO asks how things are going. And when the error inbox is flooded with a hundred variations of TypeError: cannot read property of undefined, figuring out what actually matters can feel impossible.

Even at Sentry, we're not immune to downtime. In a moment of "oh-the-irony," we once took down our own application with a bad migration. We were adding a field to a critical database table, and the migration locked it completely. Since this table was essential to Sentry’s operation, the entire app went down. The website wouldn’t load, ingestion paused—everything ground to a halt.

This guide explains how errors work in PHP and how to debug them efficiently using logging functions and Sentry. The information in this guide is correct for PHP 8 and perhaps above, depending on how much future PHP versions change.

Sentry uses Issue Grouping to aggregate identical errors and prevent duplicate issues from being created, and duplicate alerts being sent. One of the chief complaints we’ve heard from our users is that in some cases the existing algorithm did not sufficiently group similar errors together, and Sentry would create separate issues and alerts, causing unnecessary disruption–or at least annoyance–to developers.

We’ve all worked on that app that hangs just a little too long in weird places, or had that query we could never get to perform just right. The network waterfall in Chrome DevTools can’t quite show us what’s going on behind the scenes, and tracing with OTel (and honestly, tracing in Sentry) was just… hard. Today that changes.

Sentry integrates directly with the tools you already use, giving you real-time crash and performance insights for Unity, Unreal Engine, and Godot. No matter what engine you use, Sentry helps you find and fix issues before they impact your players.

During the development of your program, you might rely on simple println() statements to trace program execution flows and identify issues in your code. But as projects grow in size and complexity, print statements quickly become messy. A better approach to tracing program execution is logging, an approach that provides a consistent and organized way to track your application’s behavior, allowing you to systematically identify and resolve issues.

When debugging issues in production, context is everything. While Sentry already provides rich error data like stack traces, breadcrumbs, and user information, understanding the application state at the time of an error can still help reproduce, fix and ship quickly. Sentry’s Pinia integration solves this by automatically capturing Pinia state wherever errors occur. Now you get the complete picture of your Vue or Nuxt application's state at the moment things went wrong.

Session Replay for Mobile is now generally available. I could bombard you with hyperbolic statements about why Session Replay is worth using, but instead, A…I… wrote you a haiku: Screen freeze, devs all sigh. Replay uncovers the crime: Forgot.addListener.

There’s a common misunderstanding that profiling is only useful for tiny savings that impact infra costs at scale - the so-called “milliseconds matter” approach. But by dogfooding our own profiling tools, we fixed a problem that saved tens of seconds off each user interaction with our AI agent (and for those of you who like math, that’s four orders of magnitude bigger than those milliseconds that matter).