Mail and notifications
What your application sent, from inside the request that sent it.
What turns it on
Both are collected as part of a request, so requests.track_requests is the switch and the application has to accept Requests.
Recorded per message: the mailable class, the subject, how many recipients were on the To, Cc and Bcc, and how long the send took.
Recipients are stored as the domains a message reached, deduplicated, and not as addresses. A bounce is a bounce to gmail.com rather than to a person, and the local part is exactly the customer data this is careful not to hold.
'capture_mail_recipients' => env('LB_REQUEST_CAPTURE_MAIL_RECIPIENTS', false),
Turn it on and the full addresses are kept instead. Know what you are turning on before you do.
Notifications
Recorded per notification: the class, the channel it went out on, the type of the notifiable, and whether it succeeded or failed. The notifiable's id is not recorded: the class is diagnostic, the id is who got notified.
A failed notification is its own record rather than a missing one, which is what makes "the Slack notifications stopped going out on Tuesday" answerable.
Mail sent by a notification
A notification on the mail channel fires Laravel's mail events as well. It is recorded once, as a notification, rather than once as each.
Limits
max_mail and max_notifications are fifty apiece per request. The counters keep counting past that: a request that sent five hundred emails still says five hundred, and that request is worth a look.