-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
First draft of em concept page #14547
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,63 @@ | ||
--- | ||
title: What Is Error Monitoring? | ||
sidebar_order: 20 | ||
description: Learn how error monitoring works, why it matters, and how Sentry helps track and fix bugs in real time. | ||
--- | ||
|
||
Error monitoring is your app's always-on debugger. It tracks crashes, exceptions, and runtime issues as they happen—complete with stack traces, request data, environment details, and user context. That means you can spot patterns, prioritize what matters, and fix bugs fast (before your users even file a ticket). Think of error monitoring as a babysitter for your code, but one that actually tells you *why* the baby's crying. | ||
|
||
## Why Error Monitoring Matters | ||
|
||
Modern apps have a lot going on: different browsers, devices, APIs, cloud services... it's basically a tech jungle out there. Without proper error monitoring, bugs can sneak around unnoticed until users start bumping into them (and filing angry support tickets). That's where error monitoring comes in. It helps teams: | ||
|
||
- 🐞 **Catch issues early**, before they snowball into full-blown outages. | ||
- 🔍 **Trace bugs to their source** with rich, developer-friendly diagnostics. | ||
- 🔧 **Boost stability** by staying ahead of problems—not just reacting to them. | ||
- 🎯 **Keep users happy** by smoothing out those rough edges before they feel them. | ||
|
||
## Key Features of an Error Monitoring System | ||
|
||
A great error monitoring tool doesn't just spot bugs—it rolls up its sleeves and helps you squash them. Here's what to look for: | ||
|
||
- **Automatic Error Detection** | ||
Think of error detection as a bug-sniffing dog. It catches uncaught exceptions, failed network calls, performance hiccups across both front-end and back-end. | ||
|
||
- **Real-Time Alerts** | ||
The moment something breaks, you'll know. Whether it's via Slack, email, PagerDuty, or a smoke signal (okay, maybe not that), you'll get notified fast. | ||
|
||
- **Detailed Error Reports** | ||
No more vague “something went wrong” messages. You'll get stack traces, user info, environment details, release data, and even breadcrumbs showing exactly what led up to the bug. | ||
coolguyzone marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
- **Issue Grouping and Deduplication** | ||
Keeps your inbox (and your brain) from overflowing by bundling similar errors together. One alert for one issue—no duplicates, no noise. | ||
|
||
- **Integrations with Your Dev Toolkit** | ||
Hooks right into tools like GitHub, Jira, and CI/CD pipelines so you can trace bugs to the commit that caused them and spin up a fix without leaving your flow. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could this be a good opportunity to name-drop Seer (or at least the functionality)? Something like "and spin up a fix without leaving your flow. Or better yet, have AI do it." |
||
|
||
## Common Use Cases for Error Monitoring | ||
|
||
- Monitoring JavaScript errors in web applications | ||
- Detecting backend exceptions in Node.js, Python, Ruby, Java, or Go services | ||
- Tracking mobile app crashes on iOS and Android | ||
- Logging failed API calls and latency spikes in microservices | ||
- Catching errors during user interactions or checkout flows | ||
|
||
## The Error Monitoring Workflow | ||
|
||
1. **Install a lightweight SDK** - Set it up once, and boom: your app now has x-ray vision. | ||
2. **Let the errors roll in** - It'll auto-catch most issues, but you can log your own too (because you're thorough like that). | ||
3. **Send error data** to your monitoring platform, complete with stack traces and context. | ||
4. **Get pinged instantly** - Slack, email, carrier pigeon—whatever works. You'll know the moment something breaks. | ||
coolguyzone marked this conversation as resolved.
Show resolved
Hide resolved
|
||
5. **Fix it like a hero** - Triage, dig into the details, squash the bug, and ship with confidence. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also seems like it could be a good Seer feature drop moment! |
||
|
||
## Who's Using Error Monitoring? | ||
|
||
- **Developers**, to catch bugs in the act, trace them back to the source, and fix things *before* users start tweeting. | ||
- **QA teams**, to double-check that fixes actually fixed stuff, and keep regressions from crashing the party. | ||
- **Product teams**, to see how bugs impact real users, prioritize what matters, and keep the roadmap bug-free(ish). | ||
- **SREs**, to keep the app running smoothly, spot weird spikes, and sleep better knowing nothing's secretly on fire. | ||
- **New devs & code-curious humans** - to see what broke, why it broke, and become a better coder in the process. | ||
|
||
## Sentry's Error Monitoring Offering | ||
|
||
We're admittedly partial to [Sentry's Error Monitoring](/product/#error-monitoring), and for good reason. With real-time alerts, automatic error grouping, and actionable insights, the [Issues Page](/product/issues/) makes it easy to track and understand every bug in your code. Sentry offers SDKs for nearly every major platform, so setup is simple. You can also enhance your monitoring by adding products like [Tracing](/concepts/key-terms/tracing/), [Replays](/product/explore/session-replay/), [Prevent](/product/ai-in-sentry/sentry-prevent-ai/), and [Seer](/product/ai-in-sentry/seer/), giving you end-to-end visibility into your application's behavior. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "We're admittedly partial to [Sentry's Error Monitoring]" - does this make sense in a Sentry doc? I do see how, after reading the doc again, we're staying neutral in describing what error monitoring is, but we're already here, in Sentry. It would read more clearly if the section started with something more like "Here's how Sentry makes error monitoring a superpower in your developer toolbox". There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we expect this to be an entry point doc for Sentry newbies, let's change the Prevent and Seer terms to something people understand. Prevent = AI-driven PR review bots. Seer = an issue autofix agentic AI. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been enjoying the cheekiness of the doc overall, but this one didn't land for me. Seems like an unnecessary add. Although if you do want something cute here, maybe "by fax" instead of smoke signal?