Read the logs
$ grim logs -f app
A page returns a 500, a queued job never seems to run, a container keeps restarting. Before you change anything, read what the containers said. grim logs prints the output of the project's services, the last hundred lines of each unless you ask for more, and with -f it stays open and keeps printing as new lines arrive.
With --remote the same question goes to a deployed server instead of your own stack.
Usage
$ grim logs # every service, last 100 lines each
$ grim logs -f app # follow the app container
$ grim logs horizon --tail=500 # further back, one service
$ grim logs -f app --remote=production # the same, on the serverRun it from the project directory. A service is named as in docker-compose.yml: app, nginx, redis, mailpit, and horizon and scheduler where the project uses them.
Arguments and options
Show container logs
Usage
grim logs [-f|--follow] [-t|--tail TAIL] [--remote REMOTE] [--] [<service>]Arguments
| Argument | Description |
|---|---|
service |
Service name (optional) |
Options
| Option | Description |
|---|---|
-f, --follow |
Follow log output |
-t, --tail=TAIL |
Number of lines to show (default: 100) |
--remote=REMOTE |
Run on remote server (environment name, e.g. production) |
What it actually does
Locally it is one command, docker compose logs --tail=100, with -f and the service name added when you gave them. The output is Docker's own: each line carries the name of the container it came from.
With --remote it takes three steps.
- Finds the server. The project name comes from
deploy.projectingrim.json, orname. The host and path come from the registrationgrim server:add-projectleft in~/.grim/servers.jsonfor that environment. The path falls back to/opt/<project>, or/opt/<project>-<environment>for anything but production, which is the directorygrim server:add-projectmakes. - Connects as the
deployuser over SSH. - Runs
docker compose logsin that directory with the same--tail,-fand service. Nothing on the server is changed.
Without -f a remote read is given 60 seconds. With -f it stays open until you press Ctrl+C.
Pitfalls
Locally, the Laravel log is not in here
Containers log what they print. On your machine Laravel writes its exceptions to storage/logs/laravel.log, a file in the project directory, and grim logs app shows the output of PHP-FPM, not that file. Open it in your editor. On a server it is the other way round. The .env that grim server:add-project writes sets LOG_CHANNEL=stderr, so grim logs app --remote=production is where the exceptions are, and there is no log file to look for.
--remote knows only servers you registered
Environment 'staging' not configured for project 'shop'. means ~/.grim/servers.json on this machine has no such entry. Unlike grim env:pull, this command does not read the host from grim.json. Register the project with grim server:add-project.
Outside a project there is nothing to read
Locally the command hands over to Docker without checking where you are, so the error is Docker's: no configuration file provided: not found. Change into the project directory.
After it finishes
Once the line that matters is on screen, the usual next step is to go and look inside.
$ grim shellFor a server, the recipe Debug production walks the whole path from the symptom to the fix.
Related spells
grim shell
Step inside a container
Open an interactive bash session in the app container, or in another service of the local stack.
grim up
Raise the stack
Start the project's containers and its Vite dev server, with a trusted certificate and a working address, and say where to open it.
grim remote:shell
Step into a server container
Open an interactive bash session inside a container of the deployed project, the app container unless you name another.
grim server:status
Look over a server
List the servers you have registered, or look at one of them: its containers, its disk, Traefik and its projects.