What to do when a build stalls or fails

Record the failure symptom and original request

Record the time, task description and any job reference the interface provides. Do not erase the original attempt from your notes when trying to understand a failure. If an app or version appears later, you need a way to relate it to that request. Avoid posting screenshots containing keys, access codes or customer data when documenting the problem.

Diagnose the cause from reliable status

Use the current supported status view rather than inferring completion from a spinner or a closed tab. Distinguish queued work from running work, and both from a result you have inspected. Overskill documents separate API job references and errors; that does not mean a browser user should call endpoints or create keys to bypass a missing interface. Stay within supported account controls.

Resolve the blocker before retrying

A credit-exhaustion response differs from a temporary network problem. Overskill explicitly warns against repeatedly retrying a blocked generation. A permission error also requires a different response from a missing record. In each case, preserve the intended task and investigate the stated cause. Do not authorize a purchase or broader credential merely because an error message suggests doing so.

Verify the result before a bounded retry

Once the original state is known, decide whether a retry is safe and whether the remaining budget covers it. If the outcome is still uncertain and a repeat could create another chargeable operation, stop rather than guessing. Test the recovered output against the same acceptance criteria as the original request. A successful retry message still does not prove the app is correct, durable or ready for customers.

• Prepare a recovery note containing the original task, operation reference, last reliable status, uncertain side effects and safe next check. Never include authentication tokens or turn an unknown result into success.