Workflow guide
How to compare a failed deploy before and after a fix
Short answer
Re-running a diagnosis after a fix tells you what's resolved — but not how the run differs. A side-by-side report compare shows fixed / still-failing / newly-introduced / evidence-changed so you ship the fix with confidence.
Symptoms
- You patched env vars but aren't sure the underlying issue is gone.
- Multiple devs touched the same deploy and you need a clean delta.
- Stakeholder wants proof a P0 is actually resolved.
- Build is green but you want to confirm secondary findings didn't regress.
Common causes
- Running a single diagnosis only shows current state — no history.
- Hosting-provider logs are truncated or rotated between attempts.
- Fix landed but unrelated code changed in the same PR.
How DeployDoc checks this
- Stores each diagnosis run with its inputs and findings.
- Lets you pick two runs and diff them: fixed / still failing / newly introduced / evidence changed.
- Highlights regressions where a previously-resolved finding came back.
- Surfaces severity changes per finding between runs.
Fix it manually
- Run a baseline diagnosis on the failed deploy (paste log or upload zip).
- Apply your fix — env var, code change, dashboard setting.
- Re-run on the new build output.
- Open the Reports view, select both runs, click Compare.
- Review fixed vs still-failing vs new findings before merging.
When to run a DeployDoc diagnosis
After every meaningful fix to a broken deploy, especially before a release tag or marketing launch.