# What comes after error monitoring

CrewWork connects Sentry-powered error monitoring to HotFix. Production errors flow through a remediation pipeline that generates fixes, validates them with platform-enforced checks, and stages every change on an isolated local delivery branch: nothing ships without your review.

Your code stays on your infrastructure by default. Error monitoring, fix generation, and test validation run locally unless you configure an external integration. Push is disabled by default: every fix arrives as a reviewable change with full logs attached, and nothing leaves your environment until you opt in.

[Get in Touch](https://crewwork.ai/about/#access)

[Read the Technical Contract](https://crewwork.ai/architecture/white-paper/#sentry-bootstrap)

## From error signal to reviewed fix

CrewWork can use a self-hosted Sentry deployment or an explicitly connected external Sentry project. The pipeline is fully automated but human-controlled. Fixes land on isolated local delivery branches, and platform self-repairs land as draft pull requests (PRs), so your team decides what ships. Every fix waits for review: nothing auto-merges.

A failed attempt is discarded with its isolated worktree, as the pipeline at right shows. The pipeline never writes directly to production branches, and every change goes through your existing review process.

1

Error Captured

Your application throws an error in production. A connected Sentry project captures the exception, groups it by fingerprint, and routes it into the remediation pipeline.

2

CrewWork Triages

The webhook is verified, the error is normalized and deduplicated against known patterns. When it crosses your configured threshold, it becomes a repair candidate.

3

Fix Generated

CrewWork generates a fix in an isolated environment using your codebase context, then validates it against your build, lint, and test commands plus a quality gate covering coverage, security, and code health, with defaults like 80 percent minimum coverage and zero new critical or high severity findings. Failed attempts are discarded with the isolated worktree; your codebase is never touched.

4

Fix Ready for Review

The validated fix lands on an isolated delivery branch, marked STAGED: verified but not yet published. Validation results and execution logs stay attached to the run, linked to the originating triage record and reviewable in the Source Control surface. If you push the branch and open a pull request on GitHub, the review annotates it with code ownership and blast-radius impact analysis. Platform self-repairs open draft PRs automatically.

5

Issue Resolved

Once the fix run completes successfully and its triage record is marked fixed, CrewWork automatically marks the linked Sentry issue resolved, so your team does not have to close the loop by hand. The full error-to-fix lifecycle is tracked and auditable.

## Sentry can run with the CrewWork stack

CrewWork ships an opt-in self-hosted Sentry overlay and supports project-level external Sentry connections. The error monitoring layer runs as a two-layer control plane: platform bootstrap state for global configuration and policy, and project connect state for per-project routing and thresholds.

### Every event is verified first

Every error event is cryptographically verified with signature validation before it enters the pipeline. It tolerates multiple timestamp formats for mixed environments.

### Repairs are opt-in and budgeted

Per-integration auto-trigger, remediation policy, cooldown windows, and daily budgets gate every dispatch, and a webhook circuit breaker automatically disables a failing integration. Degraded or disabled states are surfaced with clear recovery guidance.

### Teams control when automation activates

Configure the minimum event threshold and auto-trigger setting per project, plus a separate global integration for the platform itself. Each project’s Setup tab shows its remediation posture at a glance: self-repair status, remaining daily budget, Sentry health, and review policy. Your team decides which errors warrant automated fixes and when.

### Your production code is never at risk

Every repair runs inside a gVisor kernel-isolated container on a sandboxed copy of your codebase, with hard CPU, memory, and process limits, so there is no shared state and no side effects on working branches.

### Fixes earn their way to review

Generated fixes must pass validation (test, lint, and platform-enforced checks) before the change is promoted for review, so nothing half-finished reaches review.

### Every step is logged and traceable

From error capture to review-ready fix, every decision is logged with timestamps, context, and validation outputs.

### CrewWork can add a missing Sentry SDK

If a connected project repository does not have the Sentry SDK instrumented, CrewWork can generate deterministic instrumentation scaffolding for it and, with your approval, launch a validated remediation run that applies the scaffold and stages it for your review, so error capture starts flowing without hand-written SDK boilerplate.

## Integration health you can see

Health is emitted stage-by-stage for bootstrap state, DSN sync, webhook sync, and callback verification. Stale checks report degraded status with guidance instead of suppressing signals.

State transitions are explicit and deterministic. Disconnecting an integration automatically deregisters its remote webhook, and a reconcile pass finds and cleans up any stale webhook registrations. Admins can trigger that pass from the project’s Setup tab: scan for stale CrewWork-owned hooks, see why each one qualifies, and remove them with a rescan-then-delete confirmation. No silent failures, no hidden degradation.

Healthy

DSN synced, webhooks verified, callbacks confirmed. Repairs flow normally under your configured auto-trigger policy.

Degraded

Partial connectivity. Webhook verification stale or callbacks delayed. Candidates stay visible with recovery guidance, and repeated webhook failures trip a circuit breaker that disables the integration.

Disabled

Integration explicitly turned off by configuration. The state is intentional and clearly surfaced.

Unconfigured

Required inputs missing. Setup guidance is provided. Candidates from other sources still flow through the pipeline.

## Close the loop on every Sentry alert

Error monitoring captures the signal. CrewWork acts on it. The result is faster resolution and less on-call toil.

-   A retried fix resumes its own prior reasoning instead of starting over from scratch, so remediation compounds instead of repeating work
-   Sentry issues are resolved with validated, tested code changes
-   On-call engineers review staged changes instead of writing emergency fixes
-   Error patterns build institutional knowledge within each project over time
-   Full audit trail from detection to resolution for compliance
-   Failed attempts are discarded without touching your repository

## Everything runs on your infrastructure

CrewWork runs on your infrastructure, and the bundled self-hosted Sentry overlay can run there too. Error monitoring, fix generation, and test validation stay local unless you explicitly connect an external Sentry or model provider. Configurable model stack means you choose the inference provider.

[Compare Deployment Model](https://crewwork.ai/compare/)

[Security Details](https://crewwork.ai/security/)

The platform monitors and repairs itself through this same pipeline, under stricter gates: [see Platform Self-Repair](https://crewwork.ai/self-modification/).

Technical: Sentry Bootstrap Contract

Sentry can run alongside the CrewWork stack as a self-hosted instance managed by bundled tooling, or connect through explicit project settings. One command boots self-hosted Sentry and starts CrewWork pointed at it. The bootstrap contract is a two-layer control plane in the integration model. Platform bootstrap state covers global credentials, DSN/webhook synchronization policy, and verification cadence. Project connect state covers org/project mapping, scoped queue policy, and callback routing.

-   Platform bootstrap is policy-driven from environment and service config, and DSN and webhook sync are on by default once bootstrap is enabled.
-   Project connect defines ownership and event routing via a scoped webhook endpoint with signature verification.
-   Connect state carries auto\_trigger and min\_events\_threshold so teams can tune candidate creation behavior per project.
-   Sync and webhook outputs are reconciled using idempotent registration and verification paths.
-   Webhook signatures tolerate multiple timestamp formats and fallback parsing to avoid false negatives.
-   Candidate visibility remains intact during degraded or disabled stages with clear recovery steps.

Production guidance is to treat this as a bootstrap contract, not a one-time setup step. A healthy state is expected to be maintained, monitored, and repaired with the same rigor as every other autonomous control loop.

## Stop triaging. Start resolving.

See how CrewWork turns your Sentry alerts into validated fixes.

[Get in Touch](https://crewwork.ai/about/#access)

[See How It Works](https://crewwork.ai/how-it-works/)

---

Canonical page: https://crewwork.ai/sentry/
