Deployment Evidence and Recovery

A production deployment can fail after a perfectly good local build.

Recovery begins with knowing what was deployed.

Build a deployment record

For every meaningful release, keep:

commit SHA
branch
workflow/run identifier
build status
deploy status
public URL
verification result

Failure categories

Build failed

No valid Pages artifact was produced.

Inspect build logs/dependencies/source.

Deploy failed

Build may have succeeded, but publishing the artifact failed.

Inspect deployment job/environment/permissions.

Deploy succeeded, site wrong

Now inspect:

• deployed commit;
• generated output;
• URL/base path;
• cache/propagation;
• content/config differences.

Recovery strategies

Depending on repository workflow and change risk:

• fix forward with a small reviewed commit;
• revert the breaking source commit;
• redeploy a known-good source state through the normal workflow.

Do not manually patch the live Pages output as your normal recovery method.

Reproducible rollback thinking

Identify one known-good commit in your history.

Explain how you would return the source to that behavior without deleting unrelated future history blindly.

The exact Git operation depends on the situation/team policy. The key is knowing the good state and preserving auditability.

Checkpoint

Write a deployment recovery plan that begins with evidence, names a known-good source state, and ends with public verification.