Drupal database log retention cap may delete deployment failures

Yes, Drupal core's dblog module can delete deployment failure messages before an administrator reviews them if the log reaches its retention limit between cron runs. This can happen when a high‑traffic site generates many log entries after a deployment error and the next cron execution removes the oldest rows.

How dblog Pruning Works

The dblog module records each log entry in the watchdog table. Every time cron runs, Drupal checks how many rows exist for the log type 'log'. If the count exceeds the maximum configured in Configuration → System → Logging, the system deletes the oldest rows until the total is at or below the limit. Because pruning is based on row count rather than timestamp, a failure that occurs after the last cron run and when the table is already full may be removed before anyone looks at the Recent log entries report. The default retention cap is 50 000 entries in Drupal 9/10 and 10 000 in earlier versions, and the cron interval can be hourly, three‑hourly, or custom, which further influences whether the failure survives.

Steps to Reduce Risk

1. Increase the Cap: Navigate to Configuration > System > Logging and raise the maximum number of recent messages.
2. Externalize Logs: For production environments, use a module such as syslog to forward logs to a dedicated logging service.
3. Manual Cron Trigger: If a deployment fails, run cron manually via CLI (drush php:cron) to stabilize the log state before heavy activity.

If you need to verify whether a specific failure was pruned, provide the current row count of the watchdog table and the timestamp of the last cron execution.