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 46 of 60
-
Triage a delayed symptom after a software release
A production symptom begins well after a release. Establish the delay, affected path, and intervening changes before linking the symptom to one release.
-
Prioritize a release with delayed symptom onset
Choose queue priority for a delayed release symptom based on current harm, uncertainty window, recurrence risk, and the next evidence checkpoint.
-
Investigate whether a delayed symptom traces to a release
Analyze a delayed release symptom by rebuilding the intervening timeline, comparing cohorts, and testing delayed effects without assuming causality.
-
Verify recovery from a delayed post-release symptom
Verify a delayed symptom across its original trigger and waiting period so a quiet interval is not mistaken for recovery.
-
Learn from recurring delayed release symptoms
Capture lessons from delayed release symptoms with timing context, delayed triggers, and earlier evidence that can narrow attribution.
-
Triage version skew across a release boundary
Identify a version-skew boundary during release, compare served and intended versions, and define the affected path before assigning cause.
-
Prioritize version skew during a software rollout
Decide queue priority for version skew using contract risk, affected exposure, observed harm, and how long the mismatch may remain.
-
Investigate version skew across a release boundary
Build a reproducible version-skew brief by comparing component contracts, served identifiers, payloads, and matched paths across the release boundary.
-
Verify compatibility after correcting version skew
Verify the original cross-version path with aligned identifiers, representative traffic, and downstream outcomes before declaring version skew resolved.
-
Learn from recurring version skew in deployments
Record durable release lessons from repeated version skew, including contract boundaries, transition windows, and evidence that should accompany future rollouts.
-
Triage configuration drift around a deployment
A runtime configuration differs from the reviewed baseline. Identify the changed setting, affected environment, and evidence boundary without exposing secret values.
-
Prioritize configuration drift after a release
Choose queue priority for configuration drift using customer exposure, behavior change, reproducibility, and the next safe review decision.
-
Investigate configuration drift without exposing secrets
Trace intended and observed configuration identity across release, environment, runtime, and behavior records using safe references and reproducible comparisons.
-
Verify runtime configuration matches the reviewed release
Verify configuration identity and behavior after a drift correction using safe references, affected paths, and a complete reload or exposure window.
-
Learn from recurring configuration drift after releases
Turn repeated configuration drift into a durable release lesson about baseline identity, safe evidence, reload timing, and recurrence detection.
-
Triage a rollback when serving state is uncertain
A rollback is planned or recorded, but serving state remains unclear. Separate intent, progress, exposure, and observed recovery before drawing a conclusion.
-
Prioritize a rollback with uncertain serving state
Decide how urgently to review a rollback by weighing current exposure, customer harm, recovery confidence, and the next release decision.
-
Investigate whether a rollback changed the served version
Trace rollback intent, deployment records, routing, runtime identifiers, and behavior to determine which version served the affected path.
-
Verify recovery after a deployment rollback event
Verify that the affected path serves the reviewed version and that the original symptom remains absent through the relevant exposure and delay window.
-
Learn from uncertainty during deployment rollback
Capture release lessons from uncertain rollbacks: serving identity, exposure exceptions, behavior checks, and evidence for future recovery claims.
-
Triage a recurring software release regression
A previously resolved release regression has returned. Establish whether the symptom, path, and release boundary truly match before linking the episodes.
-
Prioritize a recurring software release regression
Choose queue priority for a returning regression using current harm, recurrence confidence, fix durability, and the next release or verification decision.
-
Investigate why a release regression returned
Compare repeated regression episodes across code, configuration, exposure, verification windows, and affected behavior to produce a recurrence brief.
-
Verify a durable fix for a recurring release regression
Verify the current regression fix across the repeated path, prior failure condition, changed exposure, and delayed recurrence window.
-
Learn from a recurring software release regression
Record a durable lesson from a returning regression about prior fix coverage, release context, delayed recurrence, and future verification design.