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 for your review.
Error monitoring, fix generation, and test validation run on your infrastructure unless you connect an external Sentry or model provider. Push is disabled by default, so nothing leaves your environment until you opt in.
From error signal to reviewed fix
CrewWork can use the opt-in self-hosted Sentry overlay or an explicitly connected external Sentry project. The pipeline is automated but human-controlled: every fix waits for your review, and nothing auto-merges.
The platform monitors and repairs itself through a stricter version of this pipeline: see Platform Self-Repair.
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.
CrewWork Triages
The webhook signature is verified, then the error is normalized and deduplicated against known patterns. When it crosses your configured threshold, it becomes a repair candidate.
Fix Generated
CrewWork generates a fix in an isolated worktree using your codebase context, then validates it against your build, lint, and test commands and the project quality gate. A failed attempt is discarded with its worktree; your repository is never touched.
Fix Ready for Review
The validated fix lands on an isolated delivery branch, marked STAGED: verified but not yet published. Validation results and logs stay attached to the run, reviewable under Source Control. If you push the branch and open a pull request on GitHub, the review annotates it with code ownership and blast-radius analysis.
Issue Resolved
Once the fix run completes and its triage record is marked fixed, CrewWork marks the linked Sentry issue resolved, so your team does not 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. Configuration has two layers: platform bootstrap state for global policy, and project connect state for per-project routing and thresholds.
Every event is verified first
Every error event’s webhook signature is verified before it enters the pipeline, with tolerant timestamp parsing for mixed environments.
Automation is opt-in, per project
Set the minimum event threshold and auto-trigger per project, plus a separate global integration for the platform itself. Cooldown windows and daily budgets gate every dispatch. Each project’s settings show its remediation posture: self-repair status, remaining budget, Sentry health, and review policy.
Repairs run in a sandbox
Every repair runs inside a gVisor kernel-isolated container on a copy of your codebase, with hard CPU, memory, and process limits.
CrewWork can add a missing Sentry SDK
If a connected repository is not instrumented, CrewWork generates deterministic Sentry SDK scaffolding and, with your approval, applies it through a validated remediation run staged for your review.
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 settings: scan for stale CrewWork-owned hooks, see why each one qualifies, and remove them with a rescan-then-delete confirmation.
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.
Disabled
Turned off by configuration, or by the circuit breaker after repeated webhook failures. The state is explicit 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
On-call engineers review staged fixes instead of writing emergency ones. A retried fix resumes its prior attempt’s reasoning instead of starting over, so remediation compounds instead of repeating work, and error patterns build institutional knowledge within each project over time.
Technical: Sentry Bootstrap Contract
One command boots the self-hosted overlay and starts CrewWork pointed at it. Platform bootstrap state covers global credentials, DSN and 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.
- Sync and webhook outputs are reconciled using idempotent registration and verification paths.
- 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.