Information for: DEVELOPERS   PARTNERS

About Cloud Platform logging

Cloud Platform uses one or more servers to deliver your Drupal application. Each server generates its own log entries, and stores them in its own log files. Other than the Drupal watchdog log, there’s no single log file you can download that has data from all your application’s servers. You can view all the log entries for a Cloud Platform environment with streaming in real time either on the Applications > [Environment] > Logs page or from the command line. For information about how to use the information in logs, see Introduction to troubleshooting with log files.

You can access your application’s logs on Cloud Platform using several methods:

Log file listing

Cloud Platform makes the following logs available for your use through various methods, such as streaming, download, or log forwarding:

Log type Log file name Download Stream Description
Apache access logs access.log yes yes Contains a list of requests for your application that have bypassed Varnish®. These requests include pages, theme files, and static media files.
Apache error log error.log yes yes Records any Apache-level issues. The issues reported here are typically caused by general server issues, including capacity problems, .htaccess problems, and missing files.
Drupal request log drupal-requests.log yes yes Records all Drupal page loads on your application.
Drupal watchdog log drupal-watchdog.log yes yes Records Drupal-related actions on your application. The watchdog log is recorded on your server if you have enabled the syslog module.
FPM access logs fpm-access.log no no Records all requests handled by FPM’s process management in PHP.
FPM error logs fpm-error.log no no Records server-level issues with FPM’s process management in PHP. For application-level PHP issues, see the PHP error log.
PHP error logs php-errors.log yes yes Records any issues that occur during the PHP processing portion of a page load, including issues caused by an application’s code, configuration, or content.
MySQL slow query log   yes yes Contains a list of MySQL queries that have taken longer than one second to complete. Since slow query logs are stored in a root-only MySQL directory on your servers, you can only download them using the Logs page, and you can’t access them directly on the server. For more information, see Downloading your slow query log and Tools for parsing a slow query log.
Varnish request logs   no no Records all requests processed by Varnish, both cached and uncached. Available only to subscriptions with dedicated load balancers that forward logs to an external service.

Logging in Site Factory

In addition to the log files mentioned on this page, Site Factory offers additional audit and task logging. For more information, see Monitoring Site Factory.

Downloading active log files from the Logs page

You can download the most recent logs for each of an environment’s servers from the Logs page using the following steps:

  1. Sign in to Cloud Platform as a user with the download logs permission for the subscription and environment you want.

  2. Select the application for which you want to download a log.

  3. Select the environment for which you want to download a log.

  4. Click Logs, and then click Download.

    Downloading logs from the Logs page

  5. Click the Download link for the log you want to download. If available for immediate download, the log file will begin downloading; if the log file must be created on-demand, a dialog will display with the status of the request:

    Pending log dialog

  6. Once the log file is ready for download, click Download to retrieve it.

The log file will be downloaded as logfilename-timestamp.tar.gz.

Downloading historical logs directly from the server

You can access logs using SSH, rsync, SCP, or other tools.

Log files don’t persist after a server is relaunched or resized.

Historical logs are stored in a location on the server that’s optimized for fast read/write activity. While this works for actively and simultaneously updating several log files, the directory won’t persist after a server is relaunched or resized. Log files do persist after a server is rebooted. A relaunch can happen at any time (for instance, in the event of hardware failure). For this reason, if you want to ensure logs are stored permanently, you should routinely copy log files to permanent storage. For example, you can create a cron task that periodically copies log files to a directory in your Cloud Platform file system (such as /mnt/gfs/[site].[env]/files-private/logs), or to a remote location (such as Amazon S3).


Acquia retains subscriber server log data remotely for up to 12 months for internal compliance and security audit purposes. Since log files don’t persist after server relaunches (which happen periodically during routine maintenance events), subscribers who require ongoing and persistent access to historical server logs, should use Acquia’s Log forwarding service.

Location of log files

Each server maintains its own log files, except the Drupal watchdog log. For each server, the log file is located at /var/log/sites/[site].[env]/logs/[servername]/[logname].log. You can find your website name and server names on the Servers page. For example, the Apache error log for the Dev environment of a website named myexample on a server named srv-25 would be:


The following logs are available for download from the Cloud Platform user interface:

  • Apache access log
  • Apache error log
  • PHP error log
  • Drupal page request log
  • Drupal watchdog log


After March 2019, website requests are no longer logged to a single drupal-watchdog.log, and are instead aggregated on the server handling the request.

Archived logs

Cloud Platform creates a new server log every day and compresses, archives, and saves old logs by date in the following format (YYYYMMDD):

  • access.log-20140527.gz
  • error.log-20140527.gz
  • drupal-requests.log-20140527.gz
  • drupal-watchdog-20140527.gz
  • php-errors.log-20140527.gz

Cloud Platform archives log files by file name, and won’t archive files in the logs directory having no default names.

Accessing logs using SSH

You can access log files on a server using SSH. For example, to view the Apache access log on the specified server:

less /var/log/sites/[site].[env]/logs/[servername]/access.log

Downloading web server logs using the rsync command

You can use the rsync command from your local machine to download logs:

  1. To list the log files on your web server, use the rsync command and substitute the correct values for your application, server, and Cloud Platform SSH key pathname (typically ~/.ssh/id_rsa):

    rsync -avz -e 'ssh -i /path/private/keyfile' [username]@[host name]:[logpath]

    The rsync command produces a list like the following example:

    receiving file list ... done
    drwxr-xr-x 4096 2010/01/26 19:34:05 .
    -rw-r--r-- 83581323 2010/01/27 12:05:53 access.log
    -rw-r--r-- 214919 2010/01/27 12:04:57 error.log
    -rw-r----- 995 2010/01/27 04:15:29 php-errors.log
  2. For each file you want to download, use the rsync command and substitute the correct values for your application, server, Cloud Platform SSH key, and the file you want to download:

    rsync -avz -e 'ssh -i /path/to/private/key/file' [site name]@[hostname]:[log path]/[file name].log

    For example:

    rsync -avz -e 'ssh -i /Users/esymbolist/.ssh/id_rsa' [email protected] /mnt/gfs/home/example/logs/access.log-20151225.gz/access.log

Downloading an individual server log using the SCP command

You can use the scp command from your local machine to individual logs. To download an individual server log, use the scp command and substitute the values for your application, server, Cloud Platform SSH key pathname (typically ~/.ssh/id_rsa), and the file you want to download:

scp -i /path/to/private/key/file [site name]@[host name]:[log path]/[filename].log [local path]

For example:

scp -i /Users/esymbolist/.ssh/id_rsa [email protected]:/mnt/gfs/home/example/logs/access.log-20151225.gz/access.log /Documents/logs

Additional (inaccessible) logs

Acquia uses additional logs from the logs mentioned earlier on this page that aren’t available to subscribers. These logs are inaccessible for several reasons, including the potential for security issues related to shared resources.

  • Binary logs: Binary log (binlog) files are used to replicate data from the master database to a replica database. All statements that change data, including create, update, and delete statements, add lines to the MySQL binlogs. Queries that only read from the database, without changing the contents, don’t add lines to the binlogs. Staging environments, despite not having redundant databases, also use binlogs to keep feature and performance parity between non-production and production environments. For more information, see Binlogs.
  • Email logs: Email logs are often a shared server resource, may have sensitive information, and aren’t available to subscribers.