Capturing exceptions
An exception event is one time something threw. LaraBug groups them into issues, so the page you read is the problem and the events behind it are the times it happened.

Automatically
With register_exception_handler left at true, every unhandled exception in a listed environment is reported. There is nothing to write.
By hand
To report something you have caught yourself:
use LaraBug\Facade as LaraBug;
try {
$gateway->charge($order);
} catch (GatewayException $e) {
LaraBug::handle($e);
return back()->with('error', 'The payment did not go through.');
}
With your own context
The third argument attaches whatever you know about the moment:
LaraBug::handle($e, 'php', [
'order_id' => $order->id,
'gateway' => 'mollie',
'attempt' => $attempt,
]);
It arrives on the occurrence as its own block, beside the request and the user. Keep it small and keep it free of anything you would not want stored: it is sent exactly as given, and the blacklist does not apply to keys you invent.
Not reporting something
Two ways, and they answer different questions.
except is for exception classes that are noise everywhere:
'except' => [
Illuminate\Auth\AuthenticationException::class,
Illuminate\Validation\ValidationException::class,
],
sleep is for exceptions that are worth knowing about but not ten thousand times:
'sleep' => 60,
The same exception, from the same place, is reported once per that many seconds. Raise it on a busy application; the events you save are duplicates of one you already have.
Environments
'environments' => ['production'],
Nothing is sent from an environment that is not on this list, which is why a local machine stays quiet without any other setting. Add staging when you want staging reporting, ideally to an application of its own so a staging mistake never pages anybody.
Release tracking
Set project_version and every report carries it. An issue that starts at a version you deployed this morning is a different conversation from one that has been there for a year.