- What does timacdonald/pulse-validation-errors do?
- It is a Laravel Pulse card that surfaces validation error activity from your application inside the Pulse dashboard. Instead of adding a separate analytics tool, you get a view of which validation rules fail most, which forms and endpoints generate the most failures, and how those trends change over time. It is an observability add-on only and does not change how Laravel validation behaves.
- How do I install the package in a Laravel application?
- Installation is a normal Composer require followed by registering the package's Pulse recorder and card, then adding the card to your Pulse dashboard configuration. You need Laravel Pulse already installed, configured, and accessible in the environment where you want the card. Check the README for the exact recorder and card class names and the current registration syntax, since Pulse configuration has changed across versions.
- Which Laravel, PHP, and Pulse versions are supported?
- The package targets Laravel applications running Laravel Pulse, but the supported Laravel, PHP, and Pulse version combinations are defined in the package's composer.json and release notes. Because the last release was in June 2024, verify compatibility against your current Laravel and Pulse versions before adopting it. Build a small matrix of Laravel version, PHP version, Pulse version, and package release, and re-test after each framework or Pulse upgrade.
- Does it record every validation exception or does it sample or aggregate?
- The card is driven by a Pulse recorder, and how much it records depends on how that recorder is configured for your app. High-volume applications should confirm whether every validation failure is written or whether sampling and aggregation are available before enabling it broadly. Test in staging and inspect the volume of entries generated under realistic traffic rather than assuming the defaults fit your load profile.
- Where is the validation error data stored and what is the retention policy?
- Recorded entries are stored wherever your Pulse installation persists its data, which is typically the Pulse tables in your application's database using the configured storage connection. Retention follows your existing Pulse configuration, including any pruning or trimming you have set up, so review that before rollout. Confirm the exact schema and any package-specific configuration in the README.
- Does it capture sensitive input, field names, routes, or user identifiers?
- Validation telemetry commonly includes the failing rule, the field or attribute name, and context such as the route or endpoint, and some of that can be sensitive depending on your application. Before enabling it in production, inspect the recorded payloads in staging and check whether anything personally identifiable or tenant-identifying is being written. If sensitive values appear, use Pulse's redaction and filtering options or scope recording to non-sensitive forms.
- Can I reduce noise if my app produces a huge number of validation failures?
- Yes, but the practical levers are mostly around the recorder and the dashboard rather than the card itself. Consider sampling, limiting the time window shown on the card, scoping to specific routes or forms, and relying on Pulse's pruning to keep storage bounded. If volume is still a problem, the cleanest rollback is to unregister the recorder and remove the card from your dashboard.
- Who can view the validation errors card and how do I control access?
- Access is governed by your existing Pulse dashboard authorization, typically the gate or middleware you already configured for Pulse in production. Make sure that authorization is genuinely restricted, because validation keys and endpoint names can reveal internal structure. Treat the card as an internal engineering and support tool rather than something exposed to customers or unauthenticated users.
- Will this hurt production performance or reliability?
- Runtime risk is generally low because the package is isolated to Pulse recording and dashboard rendering, and it does not sit in your validation code path. The real concerns are database write overhead under peak validation traffic and the possibility of noisy, high-cardinality data making the card hard to read. It is a single-maintainer, low-adoption package that depends on Pulse internals, so pin the version and re-test after Laravel and Pulse upgrades.
- How do I remove the package if it does not work out?
- Removal is straightforward: unregister the recorder and card from your Pulse configuration, remove the Composer dependency, and clear your config cache. Document those steps up front so the change is reversible without guesswork. Because it is a narrow dashboard add-on, removing it should not affect validation behavior or application data.