Read a deployment log and find the failing step

Every deployment keeps its complete log, whether it succeeded or failed. When a deployment fails, nothing else you can do on the site is as quick as reading that log properly: the line that explains the failure is almost always in the last twenty lines. This article shows how to get to the log, how the two log panels are organised, how to read them, what the Why it failed card is and is not, and how to recognise the failures you will meet most.

The examples come from a Laravel site whose migration stopped a deployment, but the method is the same for every site type.

Before you begin#

• View permission. Everyone who can see a site can read its deployments and logs. Starting a new deployment (Redeploy) needs the permission to manage deployments.
• Know the order of a deployment. SrvYard prepares the server, fetches the code, writes the .env if needed, runs your deploy script, switches the release live and then runs the health check. The log follows that order, so the last step that appears is the one that failed.
• Know that a failure before the switch is safe. If a deployment fails before the release is activated, the site keeps serving the previous release and SrvYard removes the half-built one. Only a failed health check leaves the new release live.

1. Find the deployment#

Open the site and choose Deployments. The History table lists every deployment, newest first.

1. Status. Filter by Queued, Running, Finished, Failed or Cancelled. The Trigger filter next to it narrows by who or what started the run, and Search commits, authors, releases... finds a deployment by commit message, author or release name.
2. A row. The status badge (a Live badge marks the release being served now), the commit message with its short hash, branch and author, the trigger, the release name, when it started and how long it took.

Open the row menu (the three dots at the end of the row).

1. View deployment. The details page with both log panels and, for a failure, the explanation.
2. View output. A side sheet with only the log, handy for a quick look without leaving the list. It has Copy and Download buttons and a Follow switch that keeps the view at the end while a deployment is still running.

The menu also offers Roll back to this for a finished earlier release, Cancel deployment for a queued or running one and Reset stuck deployment for one that has run for over 30 minutes without reporting back.

2. Read the top of the details page#

1. Status. Next to the title and the short commit hash: Failed here. A running deployment shows Running and updates by itself.
2. The deployment failed. A red box with the one-line reason SrvYard recorded: here php artisan migrate failed: Column already exists: Duplicate column name 'discount_code'. For a failure of a script command SrvYard adds the command that failed and the last lines of its output. Secrets such as access tokens are removed from this text.
3. Why it failed. An explanation written by an AI model, described in step 4.

Below those are the Commit, Hash, Author, Branch, Triggered by (Manual deployment, Push to deploy, Deploy hook or API), Started, Duration and Release. A release that was removed by retention shows its name struck through with "(removed)", and the Rollback unavailable line says why you cannot go back to it.

3. Read the two log panels#

Scroll down to Build logs and Deployment logs. Collapse all folds both.

1. Build logs. Everything before your script: preparing the server, fetching the branch, linking shared paths and the .env. "Nothing was built yet." means the run never got that far. A rollback has no build and says so: "A rollback does not build anything: it switches back to a release that was built before."
2. Running the deploy script. The line where your own commands start. Everything below it is the output of the script, in order, with each command printed after a $.
3. The last lines. A failed deployment ends with "Deployment failed." Read upwards from there: the lines just above are the output of the command that stopped the script (here, the migration and its SQL error). A finished one ends with "Deployment finished." (or "Rollback finished.").

How to read a long log quickly:

• Go to the bottom first, then scroll up until the output of the previous command begins. That command is the culprit.
• Look for the first error, not the last. One failure often causes several messages after it.
• Note the step markers. Lines that begin with => are SrvYard's own steps: Preparing, Fetching, Running the deploy script, Activating and Health check. If "Activating" never appears, the live site never changed.
• Use View output > Download to send a log to a colleague. Logs longer than 400,000 characters are shortened to the last part and the page says so.

4. Use "Why it failed" carefully#

For a failed deployment, SrvYard can send the end of the output, with secrets removed, to an AI model and show its answer in Why it failed: a one-line summary, the most likely cause, numbered steps to fix it and a confidence label such as High Confidence. The card is clearly marked: "Written by an AI model from the end of the output, with secrets removed. Check it before acting on it."

Three things to know:

• It is a hint. The model sees only the end of the log, not your code. Always compare it with the log.
• It needs a plan that includes it and the feature turned on. On other plans the card shows See plans. The writing is also limited per hour for an organisation.
• Redeploy. The button under the explanation starts a new deployment after you have fixed the cause; it asks "Deploy again?" before it does.

5. Recognise the usual failures#

Troubleshooting#

• The log is empty or short. The deployment may still be queued ("Waiting for the deployment before this one to finish.") or it failed before the script. Read Build logs.
• "The deployment took too long and was stopped." The job as a whole ran out of time. Look at which step was last in the log.
• "The deployment job stopped unexpectedly." SrvYard lost the job. Check the server's status and try again; Reset stuck deployment frees a run that never reported back.
• A cancelled deployment. Cancelled means someone pressed Cancel deployment. The half-built release is removed and the current one stays live.
• No "Why it failed" card. The plan does not include it, the organisation switched it off, or the run was cancelled. The red failure box still has the recorded reason.
• The log does not show a secret I expected. SrvYard hides tokens and keys from deployment output on purpose.

Related#

• Write and test a deploy script: fix the command that failed.
• A deployment failed: a symptom-first checklist.
• Deploy hooks, health checks and release retention: what the health check does.
• Zero-downtime releases and rollbacks: go back to an earlier release.