Read site logs and run commands

llms.txt

When a page returns an error or a job does not run, the first questions are always the same: what does the log say, and what happens if I run this command by hand? SrvYard answers both on the site itself. The Logs tab shows the last lines of the site's own log files, and the Commands tab runs a command as the site's Linux user in the site folder and keeps the result, so there is no need to open an SSH session for the everyday cases.

This article explains what each log contains and how to read it, how refreshing works, how commands run (user, folder, time limit, history), when SrvYard asks for a second confirmation and which problems these two tabs cannot solve.

Before you begin

  • A Ready site on a connected server. Logs are read over SSH, so the site and its server must both be ready: otherwise the page says "The site and its server must be ready to read logs."
  • Permission to run commands. Everyone who can view the site can read logs. Running commands is limited to owners and admins (or a custom role with the permission to run commands). Others see the page but the Run button is disabled with the note "Only owners and admins can run commands."
  • A clear idea of what the command does. Commands run on the live site, as the site user, with no undo.

1. Choose a log

Open the site and choose Logs.

The Logs tab with its controls
Pick a log, how many lines to read, and refresh by hand or automatically.
  1. Log. Which file to read.
  2. Lines. How many lines from the end of the file: 50, 100, 200, 500 or 1000. The default is 200.
  3. Refresh. Reads the file again now.
  4. Auto-refresh. Re-reads every five seconds while the page is open. Use it while you reproduce a problem in another tab, and switch it off afterwards.

Below the controls a dark panel shows the text. "The log is empty." means the file exists but has nothing in it, or does not exist yet. Any failure to reach the server is shown above the panel in red, for example "Could not read the log: ..." followed by the reason.

The list of logs
A Laravel site offers four logs.
  1. The available logs. They depend on the site type:
Log What it contains Offered for
Nginx access log One line per request: address, time, method, path, status, size. Every site
Nginx error log What Nginx itself complains about: unreachable PHP-FPM, permission problems, rejected requests, upstream timeouts. Every site
Laravel log The application's own log under storage/logs. Laravel, and other Laravel-based types
PHP error log PHP errors and warnings from the site's PHP-FPM pool. Sites that run PHP

Static sites and Node sites therefore show only the two Nginx logs.

Reading a log

  • A 502 or 504 in the access log (the three-digit status after the request) points to PHP or your application: read the Nginx error log next, then the PHP error log. See 502 Bad Gateway.
  • A 500 with a clean Nginx error log is an application error: read the Laravel log. The newest entry is at the bottom.
  • Nothing at all in the access log usually means the request never reached this site: check domains and DNS.
  • Only the last lines are read, so for something older, raise Lines to 1000, or use the command box with grep (step 3).

2. Run a command

Open the Commands tab.

The Commands tab
Type a command or start from a suggestion.
  1. Command. The command to run, as written in a shell. Several lines are allowed; up to 4,000 characters.
  2. Run. Queues the command. The toast says "Running the command...". While one command runs, you cannot start another on the same site: "A command is still running on this site. Wait for it to finish."
  3. Try. Suggestions that fill the box with one click. For a Laravel site they are php artisan about, php artisan migrate:status, php artisan queue:restart, php artisan optimize:clear and composer install --no-dev. Other site types get php -v, composer install --no-dev and ls -la.
  4. History. The latest 20 commands run on this site, newest first, with who ran them, when and how they ended. The first row is open; press a row to read its output.

How a command runs:

  • As the site user, in the site directory. For a zero-downtime site that is the live release. The page says "Run a command as srvyard in the site directory with the site's PHP first on the path."
  • With the site's PHP first on the path, so php is the version the site uses, whatever the server's default is.
  • For five minutes at most. A command that is still going then is stopped. For longer work use a background process or the server's scheduler.
  • Without a terminal. Commands that ask questions cannot be answered: add the tool's non-interactive flag (--no-interaction, --force).
  • Output is kept with the history entry. A finished command shows Failed with its exit code in brackets when it did not succeed.
Note

The command text is recorded in the organisation's activity log, so anyone who can read it sees what was run. Never put a password or token in a command line; put it in the environment instead.

3. Useful commands

php artisan about
php artisan migrate:status
php artisan optimize:clear
php artisan queue:restart
tail -n 100 storage/logs/laravel.log | grep -i error
df -h .

The first four are the suggested ones. df -h . shows the free space of the disk the site lives on and tail ... | grep finds recent errors in a log older than the lines the Logs tab can show.

4. Commands that look destructive

SrvYard looks at the command text before it runs. When it matches a pattern for something that can delete or overwrite data, it asks again.

The confirmation for a destructive command
A command that looks destructive needs a second confirmation.
  1. The command. The dialog repeats it so you can read it once more. It says "It looks like it can delete or overwrite data. It runs as the site user on the live site."
  2. Run it. Runs the command. Cancel closes the dialog and nothing runs.

The check covers recursive or forced rm, mkfs, dd if=, shred, truncate, chmod -R and chown -R, artisan migrate:fresh, migrate:reset, migrate:rollback, migrate:refresh, db:wipe, db:seed, DROP and TRUNCATE of tables, databases and schemas, git reset --hard, git clean -f, killall, pkill, shutdown, reboot, composer remove and composer clear-cache. It is a safety net, not a guarantee: a command written in another way is not recognised, so read every command twice.

Troubleshooting

  • "The site and its server must be ready to read logs." The site is installing or the server is not connected. Wait or fix the server first.
  • "Could not read the log: ..." SrvYard could not reach the server. The reason follows the colon: a refused SSH connection or a timeout. Try Refresh again.
  • "The log is empty." A new site has no entries yet, or the log file was rotated. Raise Lines or request the site once.
  • The command hangs and stops after five minutes. It is probably waiting for input. Add a non-interactive flag, or run it as a background process.
  • "The site must be installed before you can run commands." The site is not Ready.
  • command not found. The tool is not installed for the site user, for example npm on a site without Node. See Node.js versions and package managers.
  • "Permission denied" on a file. A file belongs to another user, often root after a manual sudo. Fix the owner on the server from an SSH session as an administrator.
Last updated 2026-10-247 min readNeed help? Contact support