Build logs answer build questions
When a deployment fails before it goes live, inspect its build output. Dependency installation, the selected command, required configuration, and the expected output directory are useful places to start. Find the first relevant error rather than treating every later failure as a separate root cause.
Ask the agent to connect the error to the project’s actual configuration. Repeated deployment attempts without a change in source or settings are unlikely to resolve a deterministic build problem.
Runtime logs answer application questions
If the site is live but a user flow fails, describe the route, action, and approximate time. Inspect runtime logs for that app and distinguish application errors from unavailable external services. A successful homepage request does not prove every form or API call works.
Use a bounded log range when possible. Enough context to explain an error is useful; a full dump of unrelated activity makes investigation harder and can expose information that does not belong in a shared conversation.
Close the loop on the real workflow
After correcting a problem, redeploy or restart only as the change requires, then repeat the original failing action. Check the live response and relevant logs. A green deployment status is a useful signal, but the user-facing behavior is the test that matters.
If the failure remains, keep the new evidence and revise the diagnosis. Report an unresolved external dependency honestly rather than replacing the failed action with a simulated success message.