Accessing logs

Logs for various tasks on an application container are available in the /var/log directory. They can be accessed on the normal shell after logging in with platform ssh.

Alternatively, they may also be accessed remotely using the platform log command. The CLI lets you specify which log file to access (the name of the file below minus the .log extension, as well as view the entire file in a pager, only the most recent lines, and so forth.

Run platform log --help for complete documentation.

A number of different log files are available depending on the application container in use.

Although the files in /var/log are writable, they should not be written to directly. Only write to it via standard logging mechanisms, such as your application’s logging facility. If your application has its own logging mechanism that should be written to a dedicated logs mount in your application.

All log files are trimmed to 100 MB automatically. But if you need to have complete logs, you can set up cron which will upload them to third-party storage. Contextual Code made a basic and well-described example how to achieve it.


This is the raw access log for the nginx instance running on the application container. That is, it does not include any requests that return a redirect or cache hit from the router.


Any log messages generated by the application will be sent to this file. That includes language errors such as PHP Errors, Warnings, and Notices, as well as uncaught exceptions.


The cron log contains the output of all recent cron executions. If there is no cron hook specified in the container configuration then this file will be absent. It also will not exist until the first time cron has run.


The deploy log contains the output of the most recent run of the deploy hook for the container. If there is no deploy hook then this file will be absent.


All DNS queries made by processes in the container (the application, crons, etc.) will be sent to this file.


nginx startup log messages will be recorded in this file. It is rarely needed except when debugging possible nginx configuration errors. This file is not currently available using the platform log command.


nginx-level errors that occur once nginx has fully started will be recorded here. This will include HTTP 500 errors for missing directories, file types that are excluded based on the file, etc.


On a PHP container, the php.access.log contains a record of all requests to the PHP service. These requests are split in several parts into the logs.

The php.access.log may look similar the following:

2021-07-01T13:57:12Z HEAD 200 284.288 ms 10240 kB 38.69% /
2021-07-01T13:57:13Z POST 200 162.106 ms 10240 kB 61.69% /wp-cron.php?doing_wp_cron=0123456.789
2021-07-01T14:02:13Z HEAD 200 305.745 ms 10240 kB 39.25% /
2021-07-01T14:02:13Z POST 200 168.507 ms 10240 kB 65.28% /wp-cron.php?doing_wp_cron=0123457.789

It is consisting of several parts. Let’s have a look first, at how the log is formatted, which we can get from PHP’s settings.

web@app.0:~$ cat -n /etc/php/7.4-zts/fpm/pool.d/www.conf  | grep "access.format"
   319	;access.format = "%R - %u %t \"%m %r%Q%q\" %s %f %{mili}d %{kilo}M %C%%"

Please note that the path may change based on the version of PHP you are using.

The final access.format value contains the following:

  • %R : remote IP address
  • %u : remote user
  • %t : server time of receiving request (timestamp)
  • %m : HTTP request methods - more details can be found here
  • %r : request uri
  • %s : HTTP response status codes - more details can be found here
  • %f : script filename
  • %d : time taken to serve request (in miliseconds)
  • %M : peak memory allocated by php (in kilobytes)
  • %C : CPU used by each request

Not all of these are always displayed. In the previous example for instance, %R, %u and %f are not shown.


The post_deploy log contains the output of the most recent run of the post_deploy hook for the container. If there is no post_deploy hook then this file will be absent.