Logging considerations during production

Limit the level to be logged

Each log entry in TYPO3 is associated with a severity level. For details on log levels, refer to the TYPO3 documentation: Log levels.

During development, it is often useful to log detailed information. In production, logging should be limited to important issues—typically messages at the ERROR level or higher—to reduce disk usage and improve performance.

By default, when the Application Context is set to Production, only messages with a severity of \Psr\Log\LogLevel::ERROR or higher are logged.

You can also configure different writers for specific log levels. This allows you to, for example, write warnings and errors to separate files, or ignore lower-severity messages altogether.

The following example demonstrates how to configure log writers per log level:

<?php

declare(strict_types=1);

use Psr\Log\LogLevel;
use TYPO3\CMS\Core\Log\Writer\FileWriter;
use TYPO3\CMS\Core\Log\Writer\NullWriter;

$GLOBALS['TYPO3_CONF_VARS']['LOG']['writerConfiguration'] = [
    LogLevel::WARNING => [
        // Explicitly disable warning level logs
        NullWriter::class => [],
    ],
    LogLevel::ERROR => [
        FileWriter::class => [],
    ],
];

Monitor the log and address common log entries

Some log messages may appear frequently without indicating a critical or harmful issue. For example, an outdated TypoScript condition written in legacy syntax can trigger log entries every time TypoScript is evaluated for a page.

Fixing such recurring issues helps reduce the size of your log files and improves the overall quality and maintainability of your code base.

Use system-Level log management tools

In addition to TYPO3's internal logging features, it is common practice to use server-level tools to manage log files. These tools can rotate, archive, compress, and delete log files based on size, age, or other criteria.

On Linux systems, consider using the following tools:

• logrotate – A standard utility for automatic log rotation, commonly pre-installed on most Linux distributions. It can be configured to manage TYPO3 logs and system logs.
• systemd-journald – If your server uses systemd, you can use journald for logging, with configurable rotation and retention.
• cron jobs with custom scripts – For more specific needs, administrators can use scheduled scripts to archive or delete logs periodically.

Use centralized error monitoring (e.g., Sentry)

In many production environments, it is common to offload error tracking to a centralized service like Sentry. These tools capture unhandled exceptions and application errors with full context, including stack traces, request details, and environment variables.

Sentry can often replace the need for local error log management, especially when it is used as the main tool for observing application behavior and alerting failures. However, local logs may still be useful for storing lower-level messages, audit trails, or when dealing with infrastructure-related issues.

TYPO3 supports Sentry integration via third-party extensions such as:

• networkteam/sentry-client (A Sentry client for TYPO3)

Disabling the deprecation log on production

By default, when the Application Context is set to Production, the deprecation log is disabled.

Check the log directory, for example /path/to/project/var/log and ensure no logfile has been written with deprecation in the name.

As best practice you should only configure deprecation logs for Development contexts, for example:

<?php

use Psr\Log\LogLevel;
use TYPO3\CMS\Core\Core\Environment;
use TYPO3\CMS\Core\Log\Writer\FileWriter;

if (Environment::getContext()->isDevelopment()) {
    $GLOBALS['TYPO3_CONF_VARS']['LOG']['TYPO3']['CMS']['deprecations']
    ['writerConfiguration'][LogLevel::NOTICE][FileWriter::class]
    ['disabled'] = false;
}

If the deprecation log is still being written in production, you can explicitly disable it by unsetting its configuration:

<?php

declare(strict_types=1);

use TYPO3\CMS\Core\Core\Environment;

// Add this at the very bottom of your system/additional.php
// Or your site packages ext_localconf.php to override settings
// made by other extensions
if (Environment::getContext()->isProduction()) {
    unset($GLOBALS['TYPO3_CONF_VARS']['LOG']['TYPO3']['CMS']['deprecations']);
}

If the deprecation log continues to be written, check the following:

1. Verify the Application Context

   The current context (e.g., Production) is shown in the top bar of the TYPO3 backend under the System Information module.

2. Check the resolved configuration

   Use the System > Configuration module (requires typo3/cms-lowlevel ) to inspect the effective value of $GLOBALS['TYPO3_CONF_VARS']['LOG']['TYPO3']['CMS']['deprecations'].

3. Look for overrides in extensions

   Some extensions may override logging settings in their ext_localconf.php or ext_tables.php. Check these files if your configuration appears to be ignored.

Securing TYPO3 logs in production

TYPO3 logs may contain sensitive information that could be exploited by an attacker to gain information about your system. Logs may also include personal data such as IP addresses, which must be handled with care to ensure privacy compliance.

In Composer-based TYPO3 installations, logs are written to /path/to/project/var/log by default. Since this directory is located outside the web server’s document root (/path/to/project/public), it cannot be accessed directly from the internet—providing a level of built-in security.

In Classic-mode TYPO3 installations, logs are stored in /path/to/project/typo3conf/var/log. Because the document root in Classic mode typically points to /path/to/project, this log directory is publicly accessible by default. Additional precautions must be taken to prevent unauthorized access.