Log

The log in Drupal is the running record of what the site did and what went wrong: errors, warnings, notices and informational messages. Each entry has a type, a severity, a timestamp and a message. Core's Database Logging module keeps the entries in the database and lists them under Recent log messages in the admin interface.

How logging works in Drupal 11

Code writes to the log through the logger.factory service. It returns a channel, an object that follows the PSR-3 LoggerInterface. The channel name can be any string; by convention it is the name of the subsystem, so a module logs under its own name. Procedural code can call \Drupal::logger('my_module'). A class can receive the factory through dependency injection; the comments on LoggerChannelTrait say that services should inject the logger directly instead of using the trait.

The channel passes each message to every service tagged logger. Database Logging is one of them, and Syslog is another. Severity follows the RFC 5424 levels in RfcLogLevel: emergency (0), alert, critical, error, warning, notice, info and debug (7).

Database Logging inserts a row into the watchdog table for each message, with the user, type, message text, severity, request location, hostname and timestamp. The Standard and Minimal install profiles list it as a module to install. The report offers filters for Type and Severity. Two more reports use the same data: Top 'page not found' errors and Top 'access denied' errors.

The table is trimmed by cron. The module's cron hook counts back row_limit rows from the newest and deletes the older ones. A limit of 0, shown as All, skips the trimming.

Example

A custom module records a failed import, with the title in a placeholder:

\Drupal::logger('my_module')->error('Import failed for %title.', ['%title' => $title]);
        

On the command line, Drush reads the same table. This lists the last 20 entries of that type:

drush watchdog:show --type=my_module --count=20
        

The command has the short alias ws. drush watchdog:tail (alias wt) follows new messages.

Common mistakes

• Mixing up logging and error display. The Error messages to display setting on the logging page controls what visitors see on screen: None, Errors and warnings, All messages, or All messages, with backtrace information. Its help says production sites should not display errors, and the install value is to hide them. Core's error handler writes PHP errors to the log under the type php before it decides what to show, so hiding them on screen does not remove them from the log.
• Logging everything as an error. If routine events use the error level, real problems drown in the Severity filter. Pick the level that matches the event.

For marketing and content teams

Two reports help beyond debugging. Top 'page not found' errors lists the missing addresses visitors asked for, which is a quick way to find broken links after a relaunch. Top search phrases, available when the Search module is installed, lists the searches that were logged. Ask your developers for the View site reports permission if you need them. Routine checks of these reports belong with system administration.

Sources

• Drupal core 11.4.10: Database Logging module help text
• Drupal core 11.4.10: dblog routing
• Drupal core 11.4.10: dblog.settings.yml
• Drupal core 11.4.10: DbLog logger
• Drupal core 11.4.10: LoggerChannelInterface
• Drupal core 11.4.10: RfcLogLevel
• Drupal core 11.4.10: Logging and errors form
• Drupal core 11.4.10: Syslog module help text
• Drupal core 11.4.10: Standard install profile
• Drupal core 11.4.10: Minimal install profile
• Drupal core 11.4.10: errors.inc (PHP error logging)
• Drupal core 11.4.10: LoggerChannelTrait
• Drush watchdog:show command
• Drush watchdog:tail command