Recover lost terminal output after failed deploy
A deploy failed, the terminal window closed, and the error scrollback is gone. This guide shows immediate recovery steps for Linux and Windows, then how to capture deploy output permanently.
Rao Aadil, India 5 min read
Confirm the symptom: the deploy failed and the terminal is closed
You ran a deploy, it failed, and the terminal window is gone. The command exited with a non-zero exit code, you closed the window before reading the error, and now the scrollback is gone. Re-running the deploy may not reproduce the failure, so the missing output is the core problem. Without the error message, finding the cause is guesswork.
“It ran, something broke, and the terminal that had the output is closed.”
Output is streamed and kept, so the failure is still there to read afterwards. It reads the actual error rather than reporting that the script exited non-zero, and can fix the script with you.
It reads the real state of the server before it says anything, shows you the exact command, and waits for your approval. Windows and Linux, over the SSH access you already have.
Immediate recovery: try to get the output back
The output may still exist somewhere else. Check these locations in order.
Terminal multiplexers
If you ran the deploy inside tmux or screen on Linux (including WSL on Windows), the session may still be running. Reattach with:
tmux attach
screen -r
If you're unsure which sessions exist, list them with tmux ls or screen -ls. Windows Terminal does not support reattaching to a closed tab; if you used tmux or screen inside WSL, run those commands in the WSL terminal.
Shell history
The deploy command may be in shell history, which helps you reconstruct what ran.
history
Linux also keeps a persistent history file, usually ~/.bash_history:
grep deploy ~/.bash_history
Windows PowerShell keeps the current session history in Get-History, but the persistent PSReadLine history is stored at:
$env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt
Search it with:
Select-String -Path $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt -Pattern 'deploy'
System logs
Linux system logs may record the failed service or deploy command.
journalctl -xe --since '1 hour ago'
On distributions that use syslog, check /var/log/syslog.
On Windows, open Event Viewer under Windows Logs > Application or System, or query from PowerShell:
Get-WinEvent -LogName Application -MaxEvents 50
CI/CD logs
If the deploy ran in a pipeline, the console logs are retained. Check Jenkins job console output or GitHub Actions run logs. Retention settings live in your Jenkinsfile or workflow configuration.
Application and server logs
The application or web server may have logged the failure. On Linux, check the nginx error log:
grep -i error /var/log/nginx/error.log
For containerized deploys, check Docker logs:
docker logs <container-name>
On Windows, IIS logs are under C:\inetpub\logs\LogFiles. Search them with:
Select-String -Path C:\inetpub\logs\LogFiles\*.log -Pattern 'error'
Docker logs work the same on Windows:
docker logs <container-name>
If none of these contain the missing output, the output is lost. Focus on prevention.
Find the cause: use persistent output to locate the actual error
Once you have a log file or captured output, search it for error signatures. On Linux:
grep -i error /path/to/log
On Windows PowerShell:
Select-String -Pattern 'error' -Path C:\path\to\log
Look for common deployment failure signatures: permission denied, port already in use, missing packages, configuration syntax errors, nginx: [emerg] invalid parameter, duplicate server block, and web.config errors after an IIS change. The specific signature tells you whether the failure is in build, configuration, or runtime.
Fix the deployment once you have the error
Apply the fix that matches the actual error—correcting an nginx config, adjusting file permissions, setting environment variables, or reverting a bad web.config change. Do not re-run blind.
Re-run the deploy with logging enabled to verify the fix and capture the output. On Linux, use the script command:
script -c 'your-deploy-command' deploy.log
On Windows PowerShell, start a transcript before the command and stop it afterwards:
Start-Transcript -Path deploy.log
your-deploy-command
Stop-Transcript
Some deployment tools can read the failure output for its cause and show the fix inline, which avoids this manual search entirely.
Prevent losing terminal output in future deploys
The most reliable approach is to never depend on terminal scrollback alone.
Redirect output to a file while still watching it
On Linux:
your-deploy-command 2>&1 | tee deploy.log
On Windows PowerShell:
your-deploy-command 2>&1 | Tee-Object -FilePath deploy.log
This writes a copy to deploy.log while still showing output in the terminal. The file survives a closed window. Put the tee or Tee-Object command inside your deploy script so every run logs automatically.
Use a terminal multiplexer or persistent session
On Linux, run deploys inside tmux or screen. You can detach and reattach later, even if the terminal emulator closes. On Windows, use tmux inside WSL, or run the deploy inside a PowerShell script that logs with Start-Transcript. Windows Terminal does not have native persistent sessions.
Run deploys in CI/CD with log retention
Jenkins and GitHub Actions keep console logs for every build, including failures. Define the deploy in a Jenkinsfile or GitHub Actions workflow so the output is stored on the CI server, not just the terminal.
Use a deployment tool with an audit log
An AI-assisted deployment tool streams each deploy step live and keeps an audit log, so the deploy steps are recorded even if the terminal closes. It can read a failure for its cause while it runs, giving you the error context without manually searching logs.
