From software problem to a clear next step.
Choose a topic and what you need to do next. Add a search phrase to find a specific problem.
Browse 20 topics
Explore the playbooks
1500 guides · Page 45 of 60
-
Triage a post-release error spike without guessing cause
A new error spike follows a release. Frame the affected path, timing, users, and evidence before anyone assumes the deploy caused it.
-
Prioritize an error spike after a production release
Decide whether a post-release error spike belongs at the front of the queue using user impact, confidence, blast radius, and a clear next review point.
-
Investigate whether a release explains an error spike
Build a reproducible brief for a post-release error spike by comparing release boundaries, request examples, dependencies, and unaffected paths.
-
Verify recovery after a release-linked error spike
Define evidence that shows a release-linked error spike has recovered, remains contained, or needs more observation without claiming success too early.
-
Learn from a recurring post-release error spike
Turn repeated post-release error spikes into durable release lessons by recording detection gaps, discriminating evidence, and recurrence signals.
-
Triage divergent behavior during a partial rollout
A staged release differs across cohorts or regions. Identify the boundary, affected slice, and comparison cohort before treating divergence as a global regression.
-
Prioritize a partial rollout with divergent outcomes
Choose attention and rollout review priority when only one cohort or region shows a release problem, using exposure, harm, reversibility, and evidence quality.
-
Investigate why a partial rollout diverges by cohort
Build an evidence-backed comparison for partial-rollout divergence across regions, tenants, or versions without mistaking exposure for root cause.
-
Verify a staged rollout after cohort divergence
Verify that a partial rollout is safe to continue by checking exposed and control cohorts on the original behavior, path, and time boundary.
-
Learn from repeated partial-rollout divergence
Capture durable release lessons when staged rollouts repeatedly diverge, including cohort definitions, missing controls, and earlier evidence to collect.
-
Triage a deployment with mismatched environment context
A release signal points to the wrong environment or version. Establish the intended target, observed target, and evidence boundary before comparing outcomes.
-
Prioritize an environment mismatch in release evidence
Decide how urgently to resolve an environment mismatch by weighing customer exposure, release uncertainty, reporting impact, and the next safe review point.
-
Investigate an environment and deployment identity mismatch
Trace environment identifiers from deployment record to traffic and signals, producing a reproducible explanation for where the mapping diverged.
-
Verify corrected environment context for a deployment
Verify that deployment evidence now names the intended environment and still matches observed version, traffic, and release timing.
-
Learn from recurring environment context mismatches
Record release-process lessons from repeated environment mismatches so future deployment evidence carries stable identity and clear boundaries.
-
Triage a release record with missing commit context
A deployment lacks a reliable commit, branch, or repository reference. Bound what can still be compared and identify the smallest missing context.
-
Prioritize recovery of missing deployment commit context
Choose whether missing commit context should lead the queue by weighing release risk, comparison value, customer exposure, and the timing of the next decision.
-
Investigate missing commit context in deployment evidence
Reconstruct deployment identity from repository, build, runtime, and release records while keeping inferred relationships separate from exact evidence.
-
Verify commit identity attached to a deployment
Verify that a deployment record points to the intended repository and commit using independent release and runtime evidence.
-
Learn from recurring missing commit context in releases
Turn repeated missing commit references into a durable release lesson about identity capture, fallback evidence, and recurrence review.
-
Triage a deployment rollout that appears to be stalled
A rollout has not reached its expected state. Establish the last observed transition, current exposure, and missing evidence before calling it stuck.
-
Prioritize investigation of a stalled rollout
Decide how urgently to review a stalled rollout using customer exposure, elapsed uncertainty, reversibility, and the next release decision.
-
Investigate a rollout that stopped progressing
Build a reproducible timeline for a stalled rollout by comparing status transitions, exposure records, approvals, and independent runtime evidence.
-
Verify progress or containment after a stalled rollout
Verify that a stalled rollout has resumed, remains safely held, or has a known exposure boundary using fresh state and runtime evidence.
-
Learn from repeated stalled rollout investigations
Record release lessons from recurring stalled rollouts, including missing milestones, ambiguous exposure, and the evidence needed for earlier decisions.