Pulse Validation Errors Laravel Package

Getting Started

composer require timacdonald/pulse-validation-errors

# optional – tune ignore rules etc.
php artisan vendor:publish --tag="pulse-validation-errors-config"

Register the card on your Pulse dashboard (typically app/Providers/PulseServiceProvider.php):

use Laravel\Pulse\Facades\Pulse;
use Timacdonald\PulseValidationErrors\Livewire\ValidationErrors;

Pulse::dashboard(function ($dashboard) {
    $dashboard->add(ValidationErrors::class);
});

No other wiring is required — the package registers the recorder automatically, hooks into Laravel's validation exception flow, and starts storing entries under its own Pulse type (validation_errors).

First use case: ship it, leave it running for a day, then open Pulse and look at the highest-count messages. The card surfaces the actual failure text (e.g. "The email field must be a valid email address.") so you can immediately spot form copy that users trip over, fields that should be optional, or a front-end sending the wrong shape of data. That first report usually produces three or four quick wins in onboarding/funnel screens.

Implementation Patterns

• Triage loop. Treat the card as a top-N of your worst error copy. Group by message, identify which screen it comes from, fix the validation rule or the UX hint, redeploy, and watch the count drop. Repeat weekly.
• Ignore expected noise. In config/pulse-validation-errors.php, add regexes for messages you don't want to count — e.g. /The (email|password) field is required/ on a login form where a blank submission is normal. This keeps the card focused on genuinely surprising errors.
• Pair with the slow requests / user requests cards. A spike in a specific validation message almost always correlates with a spike in a form endpoint. Cross-referencing the two makes root-causing faster than reading logs.
• Segment by deploying around it. The card is a rolling window (Pulse's period selector — 1h / 24h / 7d). Deploy a copy fix and compare the same window day-over-day rather than looking at the absolute number.
• Local verification. Trigger a known failure (e.g. submit email=not-an-email to a form) and confirm it shows up in the card. This is the fastest way to prove the recorder is wired correctly before trusting production numbers.
• Custom dashboards. Because it's a normal Pulse Livewire card, you can drop it into any dashboard alongside SlowRequests, Exceptions, etc., and control placement with $dashboard->add(ValidationErrors::class, 'full') for width.
• Extension point. Publish views (if you need different column labels or formatting) and keep the recorder untouched — the recording logic (event capture + Pulse::record) is where you should not diverge.

Gotchas and Tips

• Only ValidationException is captured. Authorization failures, manual abort(422), $validator->errors() that you return without throwing, and custom exceptions that look like validation errors won't be recorded. If numbers feel low, this is the first thing to check.
• Caught exceptions may not record. If you try/catch a ValidationException and render your own response, the recorder may never see it. Let it propagate to Laravel's handler, or trigger a recorder manually if you need parity.
• Context matters. Jobs, console commands, and queued form-submit pipelines don't have the same request lifecycle; verify they show up if you care about them. Historically this card is most useful for browser-facing form failures.
• Pulse must actually be enabled and ingesting. It's easy to install the card on a dashboard that never renders because Pulse::ingest() or the pulse queue/pulse:check isn't running. If the card shows "No validation errors", confirm other Pulse cards are populated first.
• Sampling stack-up. Pulse itself has a sample rate, and the package's recorder has its own. Low sample rates mean low counts — don't interpret a drop in numbers as a drop in real errors without checking config.
• Regex ignore rules are easy to over-match. Anchor them (/^The email field is required$/) and be specific; a loose pattern will silently hide the errors you actually wanted to see. Test rules by triggering the message and confirming the card stays empty.
• Config caching. After editing config/pulse-validation-errors.php in production, run php artisan config:clear (or redeploy with a fresh config cache). Silent no-ops after a config change are almost always a stale cache.
• Message text is a moving target. Copy changes and translation files will look like "new" errors because the message string is the aggregation key. Prefer fixing copy deliberately and watching the delta, not chasing every new row.
• Long messages can swamp the card. If you have a dynamic validation message with user input in it (e.g. "{$value} is not available"), every value becomes a distinct row. Normalise such messages in your validator rather than relying on the card to filter them.