By default, Ignition and the Flare PHP client (if you're using Flare in a non-Laravel application) will always send all the exceptions and errors to Flare.
In the cases where you don't want all exceptions being sent to Flare, you can from now on filter the exceptions sent using a callback:
// in ignition
Flare::filterExceptionsUsing(
fn(Throwable $throwable) => !$throwable instanceof AuthorizationException
);
// in the flare-php-client
$flare->filterExceptionsUsing(
fn(Throwable $throwable) => !$throwable instanceof AuthorizationException
);
When a PHP error is thrown, you can now configure which levels of errors should be sent to Flare:
// in ignition
Flare::reportErrorLevels(E_ALL & ~E_NOTICE);
// in the flare-php-client
$flare->reportErrorLevels(E_ALL & ~E_NOTICE);
In this case, Flare will send all PHP's internal errors except E_NOTICE errors.
Continue reading
Why we removed AI solutions from Flare
AI generated solutions are dead, long live AI generated solutions! We removed the old one-shot fixes from a model that could only see the stack trace. It simply couldn't compete with modern agentic AI. In their place, Flare works with the agentic AI tools you already use: an MCP server that handles real triage, a CLI with an agent skill, quick Copy for AI prompts in the UI and docs served as markdown. Hosted agents are in the works too.
Alex
Flare now uses OAuth for MCP, the CLI, and API
Connect MCP clients like Claude and Cursor to Flare by logging in from your browser, no more copying API tokens. Every connection gets its own permissions, so you can give your AI read-only access to a single project. The CLI signs in the same way, and new personal access tokens with scopes and expiry cover scripts and CI.
Alex
Subscribe to Backtrace, our quarterly Flare newsletter
No spam, just news & product updates