Sentry Bug Operations Demo

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project: Sentry Bug Operations Demo

Github Link : https://github.com/SummerSage114/sentry-bug-ops-demo.git

This project is a small production-incident management and observability application built with Flask and Sentry. It demonstrates the complete lifecycle of a production bug: detection → triage → containment → root-cause analysis → fixing → verification → prevention.

The application deliberately simulates three common production failures:

API 500 errors caused by missing input validation.
Application crashes caused by unexpected or unavailable data.
Database/performance failures caused by a slow operation.

Each incident is captured by Sentry and recorded in a local incident dashboard, where the developer can inspect the problem, apply a containment action, resolve the incident, and track preventive measures.

What problem were we solving?

Production bugs are not just a matter of finding and fixing an exception. A useful incident-response workflow needs to answer several questions quickly:

What went wrong?

Which users or releases are affected?
What caused the failure?
Can the problem be contained before it causes more damage?
Has the fix actually worked?
How can we prevent the same problem from returning?

The project was optimized for fast production diagnosis and controlled recovery, rather than simply displaying error messages.

For example, when an API begins returning 500 errors, the system can use Sentry to identify the error and its context, temporarily contain the affected functionality, investigate the root cause, deploy a fix, and then monitor Sentry to verify that the error rate has returned to normal.

Technical approach

The application uses Python/Flask with the Sentry Python SDK.

Sentry is initialized with the Flask integration:

sentry_sdk.init(
    dsn=os.getenv("SENTRY_DSN", ""),
    integrations=[FlaskIntegration()],
    traces_sample_rate=1.0,
    environment=os.getenv("APP_ENV", "production-demo"),
    release=os.getenv(
        "APP_RELEASE",
        "sentry-bug-ops-demo@1.0.0"
    ),
)

This gives the application centralized error and performance telemetry while keeping the Sentry configuration outside the source code through environment variables.

When an error occurs, we attach additional context instead of sending an isolated exception:

sentry_sdk.set_tag(
    "incident_category",
    "api-500"
)

sentry_sdk.set_context(
    "incident",
    {"summary": summary}
)

sentry_sdk.capture_exception()

This makes the Sentry event more useful during triage because incidents can be grouped and analyzed according to their category and execution context.

Containment

A key design decision was to demonstrate that detection and fixing are not the same as containment.

The application therefore includes simple feature switches:

FLAGS = {
    "checkout_enabled": True,
    "slow_db_enabled": True,
}

When an incident is detected, the problematic functionality can temporarily be disabled rather than allowing the same failure to continue affecting users.

For example:

if not FLAGS["checkout_enabled"]:
    return jsonify({
        "status": "contained",
        "message": "Checkout is temporarily disabled."
    }), 503

This models a real production practice such as feature flags, kill switches, traffic reduction, or rollback.

Performance monitoring

The database failure scenario demonstrates performance monitoring rather than only exception monitoring:

start = time.perf_counter()
time.sleep(2.2)
duration = time.perf_counter() - start

sentry_sdk.set_measurement(
    "demo.db.duration",
    duration,
    "second"
)

The Flask integration and Sentry tracing configuration allow application transactions and performance information to be observed alongside errors.

The simulated slow database operation represents a class of production problems where an application may technically be "working" but is becoming too slow and eventually producing timeouts.

Why Sentry?

Sentry was used as the central observability layer because it connects the different stages of incident response.

Instead of relying only on application logs, the developer can use Sentry's error information, stack traces, breadcrumbs, release/environment information, and performance data to move from:

"Users are reporting that something is broken"

to:

"This specific release introduced this specific failure in this specific execution path."

That makes Sentry useful not only for detecting bugs but also for determining their scope, investigating their cause, and verifying that a deployment actually resolved them.

The project uses Sentry as a core part of its architecture rather than simply adding the SDK to an otherwise unrelated application.

Sentry tools utilized

Error Monitoring

Used for the API 500 and application-crash scenarios. Exceptions are captured with additional tags and context so that production failures can be grouped and investigated.

Distributed/Application Tracing

The Sentry Flask integration and transaction tracing configuration are used to observe application transactions and investigate performance problems. This is particularly relevant to the simulated database failure, where the objective is to identify slow operations rather than only exceptions.

Release and Environment Context

The application sends explicit release and environment information:

environment=os.getenv("APP_ENV", "production-demo"),
release=os.getenv(
    "APP_RELEASE",
    "sentry-bug-ops-demo@1.0.0"
),

This allows errors to be associated with the deployment that introduced or affected them and supports regression monitoring.

Alerts

The project is designed around Sentry alerts for abnormal 5xx rates, new or recurring issues, and performance/latency thresholds. These alerts form the detection stage of the incident-response workflow.

Sentry capabilities not used

We intentionally did not claim capabilities that are not implemented in this demo.

The current version does not use Session Replay, Agent Tracing, Sentry Seer, or Sentry Logs. These could be added in a future version, but the project focuses on Error Monitoring, application tracing/performance monitoring, release context, and alert-driven incident response.

Interesting design decision

The most important design decision was treating an error as an incident lifecycle rather than an isolated exception.

A typical error-monitoring example ends with:

"Sentry detected the exception."

This project goes further:

Detect → investigate → contain → fix → deploy → verify → prevent.

The dashboard therefore keeps incident state separately from Sentry. Sentry remains responsible for observability, while the application demonstrates the operational actions that a development team takes in response to those signals.

This separation also reflects how a real production architecture can work: an observability platform detects the problem, while feature flags, deployment systems, incident-management systems, automated tests, and engineering processes handle containment and remediation.

Outcome

The result is a compact demonstration of how Sentry can become part of a complete production reliability workflow rather than functioning only as an error-reporting service.

The project demonstrates how Error Monitoring + tracing/performance data + release context + alerting + controlled containment can reduce the time between detecting a production problem and safely resolving it, while automated tests, monitoring, and regression alerts help prevent the problem from returning.