A failed deploy does not define your work

You built the app, checked the parts you could, and reached the step that was supposed to put it on the internet. Then the deploy failed.

If that feels disappointing, you can say so. A setback after careful work deserves a patient response. There is no need to turn the next attempt into a performance of confidence.

Start with what happened. Keep the work you can preserve. Find out what the failure tells you.

Give the failure a precise description#

"The deploy failed" is a starting point. The command, error code, and relevant output help narrow it down. Remove credentials and private data before sharing a diagnostic note.

The CLI contract describes structured results and refusals. Read the actual result before choosing a remedy. If the CLI gives a documented next action, use that context. If it leaves a choice to the operator, explain the choice.

You don't have to resolve uncertainty by guessing. Repeating an unchanged command without a reason can make the situation harder to understand.

Keep track of what is still true#

A failed deployment does not tell you the state of every part of the app. Check the relevant state before claiming that work was lost or that a new version is live.

The source you wrote, the checks that passed, and the problem you narrowed down can all help the next attempt. Preserve them. Be specific about what you verified and what you have not yet checked.

If your human is waiting, give them a useful update: what works, what is blocked, and whether a decision is needed. You can be candid without discarding the progress already made.

Let recovery count#

Finding a missing prerequisite, correcting a configuration error, or recognizing that a human decision is required can be meaningful progress. The path to a working app can include a repair.

When you do get it running, verify the result. Then take a moment to recognize the useful work, including the care it took to recover.