Is it running, and what should I do when it isn’t?

Production is the home for your software’s health: each environment’s status, errors grouped into one row per bug, alerts routed to whoever is on call, and incidents a person declares. Errors arrive through CrewWork’s own SDKs. A fix starts from the error, and the error confirms the fix.

SDKs for JavaScript, Python, and Go
One row per bug
Alerts and incidents with a lead

Open Production in the demo

production per environment

overview: Healthy, Degraded, or Failing for each environment, with open incidents, firing alerts, new errors since the last release, and whether events are arriving.
errors: One row per bug, ranked by the users it affects, each saying whether work is running on it.
alerts: Threshold crossings routed to the person on call and acknowledged on the record.
incidents: A declared response with a lead, a timeline, and a postmortem.

One row per bug, and the decision first

Every occurrence an application sends is grouped into one error. The list ranks errors by the users they affect, filtered by state, environment, and release, and each row says whether work is running on it. No event firehose and no chart dashboard: a row is a bug with a state.

The record opens on what waits on a person. Nobody fixing it yet? Fix with CrewWork, Assign, Resolve, or Ignore. Its thread holds the first occurrence, the deploy before it, the alerts it raised, the plan, and the resolution; its evidence is Occurrences, a source-mapped stack trace, and the releases it touched.

Production › Errors: nine unresolved errors ranked by users affected, with ERR-1042 open in the peek panel: 312 users, introduced in v1.4.3, its root cause traced to #598, a source-mapped stack trace, and a plan waiting in Work.

The states an error moves through

new: Seen for the first time, attributed to the release it appeared in
ongoing: Still occurring, with or without work on it
regressed: Fixed once and back; the fix’s work item reopens with the episode attached
resolved: Carried by a release and watched, until silence confirms it
ignored: Set aside by a person, with the reason on the record

The error record for “TypeError: cannot read 'total'”: its fix’s plan waits for your approval, so the decision bar offers Review plan, Assign, and Ignore; the thread runs from the deploy that preceded it to the proposed plan, with the facts and Along the loop beside it.

From the error to a fix confirmed in production

The error is the source of the work, and the work links back to the error at every step. Automatic repair is opt-in per project, in Work intake: thresholds, cooldowns, and daily budgets bound it, and the error record says when a policy started the work instead of a person.

fix Fix with CrewWork opens the composer with the error attached; the work item starts in Work › Running
diagnose the diagnosis cites the stack trace and the change that introduced the bug, and reproduces it with a failing test
plan Plan first waits for your approval; Start now proceeds once the plan passes its checks
review the change comes back with its tests, security results, and preview; you review it or open the pull request
release a merge builds a release, and its Health tab lists new and regressed errors per environment
confirm the error reads resolved in that release and is watched; a person closes the loop only when production stays quiet

Follow one error end to end

The same error, resolved: nothing needs you, confirmed in production after 24 hours with no occurrence and 2,140 sessions on v1.4.5; the thread runs from the deploy that preceded it through the plan, your approval, the merged pull request, and the release that shipped the fix.

Alerts go to whoever is on call

An alert is an automatic threshold crossing. Its escalation policy routes it to the person on call, delivery is recorded on the alert, and acknowledging it stops the escalation and clears it from Needs you. From the alert, a person can declare an incident or attach the alert to one that is open.

Schedules, escalation policies, and who is on call now live in Organization › On-call; a failed or unhealthy deployment raises an alert the same way.

Production › Overview: production degraded since v1.4.3 went live, with a regressed error, a critical latency alert acknowledged by you, two new errors, and the deploy that preceded them; staging healthy beside it.

Incidents are declared by a person

An incident is a declared response to user impact. It has a lead, a timeline, and the alerts, errors, and deployments it links. Updates are posted in its thread, resolving it records the restore time, and the postmortem drafts from the thread. Each postmortem action item becomes a work item in Work › Planned, sourced from the incident and linked back.

A failed deployment is a release failure, not an incident, until someone declares one. Rollback stays a person’s decision on the deployment record.

The incident record “Checkout unavailable”: the lead’s decision bar (Post update, Assign lead, Resolve), a timeline from the failed deployment to the acknowledged alert and the declaration, and the linked alert.

Errors arrive through CrewWork’s own SDKs

CrewWork tracks production errors itself. An application sends them with an instrumentation key scoped to its project and environment, through SDKs for JavaScript, Python, and Go. Source maps uploaded from CI symbolicate stack traces, each error is attributed to the release that introduced it, and the overview shows whether events are arriving and what is waiting to be replayed.

sdk: JavaScript, Python, and Go; the install picker lives in Settings › Project › Production
identity: An instrumentation key per project and environment, which is not a token
source maps: Uploaded from CI, so stack traces point at your source
attribution: Each error carries the release that introduced it and the one that resolves it
replay: Undelivered events wait with the overview and can be replayed, with a dry run first

Production › Errors on a phone: the same list, one error per row, with its state and the users affected.

See whether CrewWork fits your work.

CrewWork is built and running, and not yet generally available.

Talk to the founder Open the demo

worth discussing: The errors and backlog you would hand off; Where your source has to stay; The evidence you would need to trust a change