Logging

Logging in Laractions is deliberately small: a switch for dispatches, a helper for the inside of an action, and a line written automatically when a queued action fails. Everything goes through Laravel's logger, so channels, levels and formatting are whatever config/logging.php says.

Logging a dispatch

enableLogging() writes a line when the action is queued, with everything you need to tell an unqueued action from a stuck worker:

SendWelcomeEmail::create()
    ->enableLogging()
    ->queue('emails')
    ->delay(30)
    ->retry(3)
    ->dispatch('user@example.com', 'Welcome');

[Action: App\Actions\SendWelcomeEmail] Dispatching job. {"queue":"emails","delay":30,"tries":3,"params":{...}}

One thing to be clear about, because the name suggests otherwise: the flag only affects dispatch(). Calling enableLogging() and then run() writes nothing at all, since there is no dispatch to report. For an action that runs inline, log from inside it.

Note also that the parameters go into the log line as they were passed. The same caution as tracing applies: an action that receives a token or a password will write it to the log file if you enable this.

Logging from inside an action

Action has a protected log() helper that prefixes the message with the action class, so lines from a run are attributable without repeating the name:

class ImportCatalog extends Action
{
    public function handle(string $path): int
    {
        $this->log('Import started', ['path' => $path]);

        $count = $this->import($path);

        $this->log('Import finished', ['rows' => $count]);

        return $count;
    }
}

[Action: App\Actions\ImportCatalog] Import started {"path":"/tmp/catalog.csv"}

It writes at info level and it is not governed by enableLogging(): a call to $this->log() always writes. Treat it as the deliberate narration of the action, and keep the noisy debugging out of it.

Failed jobs

When a queued action fails for good, the job's failed() hook writes an error line with the exception message and the stack trace, prefixed with the job class. That happens whether or not logging was enabled and whether or not you have a failed_jobs table, so a failed action leaves a trace somewhere even in a minimal setup.

If you want the failure attributed to the action rather than to the job wrapper, catch it inside handle(), log with $this->log() and rethrow.

The three of them together

They answer different questions, and it is worth knowing which is which before adding more logging than you need: