Skip to content

Add --show-drupal-logs option to core:cron command to display Drupal watchdog logs #6515

@rabbitlair

Description

@rabbitlair

Is your feature request related to a problem? Please describe.

When debugging cron execution issues, the current --verbose flag outputs extensive information from both Drush's internal operations (bootstrap phases, command dispatch, etc.) and Drupal's activities. This creates significant noise that makes it difficult to identify the actual Drupal logs related to cron execution, such as which hook_cron implementations ran, what errors occurred, or what operations were performed.

For example, running drush core:cron -v produces output like:

[info] Drush bootstrap phase: bootstrapDrupalRoot()
[info] Change working directory to /var/www/html/web
[info] Initialized Drupal 10.x root directory at /var/www/html/web
[info] Drush bootstrap phase: bootstrapDrupalSite()
[info] Initialized Drupal site example.com at sites/default
[info] Drush bootstrap phase: bootstrapDrupalConfiguration()
[info] Drush bootstrap phase: bootstrapDrupalDatabase()
[info] Successfully connected to the Drupal database.
[info] Drush bootstrap phase: bootstrapDrupalFull()
... (many more Drush-specific log entries)
[info] Starting execution of system_cron()
[info] Execution of system_cron() took 450.94ms
[info] Cron run completed.

The valuable information about what actually happened during cron execution is buried among Drush's internal logging, making it hard to debug cron failures or monitor cron job execution in production environments.

Describe the solution you'd like

Add new options to the core:cron command to display only Drupal watchdog logs generated during cron execution:

  • --show-drupal-logs: Display Drupal watchdog logs generated during cron execution
  • --log-severity: Filter logs by minimum severity level (0-7, defaults to 6/info)
  • --log-type: Filter logs by type (e.g., 'cron', 'php', 'system')

Usage examples:

# Show all Drupal logs from cron execution
drush core:cron --show-drupal-logs

# Show only warnings and errors
drush core:cron --show-drupal-logs --log-severity=4

# Show only cron-type logs
drush core:cron --show-drupal-logs --log-type=cron

# Combine with other options
drush core:cron --show-drupal-logs --log-severity=3 --log-type=php

Expected output format:

[notice] Drupal logs generated during cron execution:
--------------------------------------------------------------------------------
[2026-02-06 10:15:32] [INFO] [cron] Starting execution of system_cron()
[2026-02-06 10:15:33] [INFO] [cron] Execution of system_cron() took 450.94ms
[2026-02-06 10:15:33] [ERROR] [php] Notice: Undefined variable in mymodule_cron()
[2026-02-06 10:15:34] [INFO] [cron] Cron run completed.
--------------------------------------------------------------------------------
[success] Total logs displayed: 4

This would provide clean, filtered output showing only what happened in Drupal during cron execution, without the noise from Drush's internal operations.

Describe alternatives you've considered

  1. Use watchdog:tail in a separate terminal: This requires running two commands simultaneously and doesn't capture the exact logs from a specific cron run
  2. Parse drush core:cron -v output: This is fragile and requires complex filtering to remove Drush's own logging
  3. Query the watchdog table manually after cron runs: This requires knowing the exact timing and doesn't integrate with the cron command workflow
  4. Create a wrapper script: Adds complexity and doesn't provide a native Drush solution

None of these alternatives provide the clean, integrated experience of having cron execution logs readily available.

Additional context

This feature would be particularly useful for:

  • Debugging cron failures: Quickly see which hook_cron implementation failed and why
  • Production monitoring: Monitor cron execution in CI/CD pipelines or automated deployments
  • Performance analysis: See timing information for each cron hook without Drush overhead
  • Log aggregation: Feed clean cron logs to monitoring systems without parsing Drush internals

Related issues:

The implementation would:

  • Capture the last watchdog ID before running cron
  • Execute cron normally
  • Query the watchdog table for new entries since that ID
  • Format and display them with appropriate color coding based on severity
  • Require the dblog module to be enabled (validated only when flag is used)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions