Laravel Pulse | Laravel 13.x - The clean stack for Artisans and agents

Laravel Pulse delivers at-a-glance insights into your application's performance and usage. With Pulse, you can track down bottlenecks like slow jobs and endpoints, find your most active users, and more.
For in-depth debugging of individual events, check out Laravel Telescope.
Pulse's first-party storage implementation currently requires a MySQL, MariaDB, or PostgreSQL database. If you are using a different database engine, you will need a separate MySQL, MariaDB, or PostgreSQL database for your Pulse data.
You may install Pulse using the Composer package manager:
Next, you should publish the Pulse configuration and migration files using the vendor:publish Artisan command:
Finally, you should run the migrate command in order to create the tables needed to store Pulse's data:
Once Pulse's database migrations have been run, you may access the Pulse dashboard via the /pulse route.
If you do not want to store Pulse data in your application's primary database, you may specify a dedicated database connection.
Many of Pulse's configuration options can be controlled using environment variables. To see the available options, register new recorders, or configure advanced options, you may publish the config/pulse.php configuration file:
If your cache configuration defines a serializable_classes array, you will need to add these classes to that array to support the default Pulse cards:
The Pulse dashboard may be accessed via the /pulse route. By default, you will only be able to access this dashboard in the local environment, so you will need to configure authorization for your production environments by customizing the 'viewPulse' authorization gate. You can accomplish this within your application's app/Providers/AppServiceProvider.php file:
The Pulse dashboard cards and layout may be configured by publishing the dashboard view. The dashboard view will be published to resources/views/vendor/pulse/dashboard.blade.php:
The dashboard is powered by Livewire, and allows you to customize the cards and layout without needing to rebuild any JavaScript assets.
Within this file, the <x-pulse> component is responsible for rendering the dashboard and provides a grid layout for the cards. If you would like the dashboard to span the full width of the screen, you may provide the full-width prop to the component:
By default, the <x-pulse> component will create a 12 column grid, but you may customize this using the cols prop:
Each card accepts a cols and rows prop to control the space and positioning:
Most cards also accept an expand prop to show the full card instead of scrolling:
For cards that display information about your users, such as the Application Usage card, Pulse will only record the user's ID. When rendering the dashboard, Pulse will resolve the name and email fields from your default Authenticatable model and display avatars using the Gravatar web service.
You may customize the fields and avatar by invoking the Pulse::user method within your application's App\Providers\AppServiceProvider class.
The user method accepts a closure which will receive the Authenticatable model to be displayed and should return an array containing name, extra, and avatar information for the user:
You may completely customize how the authenticated user is captured and retrieved by implementing the Laravel\Pulse\Contracts\ResolvesUsers contract and binding it in Laravel's service container.
The <livewire:pulse.servers /> card displays system resource usage for all servers running the pulse:check command. Please refer to the documentation regarding the servers recorder for more information on system resource reporting.
If you replace a server in your infrastructure, you may wish to stop displaying the inactive server in the Pulse dashboard after a given duration. You may accomplish this using the ignore-after prop, which accepts the number of seconds after which inactive servers should be removed from the Pulse dashboard. Alternatively, you may provide a relative time formatted string, such as 1 hour or 3 days and 1 hour:
The <livewire:pulse.usage /> card displays the top 10 users making requests to your application, dispatching jobs, and experiencing slow requests.
If you wish to view all usage metrics on screen at the same time, you may include the card multiple times and specify the type attribute:
To learn how to customize how Pulse retrieves and displays user information, consult our documentation on resolving users.
If your application receives a lot of requests or dispatches a lot of jobs, you may wish to enable sampling. See the user requests recorder, user jobs recorder, and slow jobs recorder documentation for more information.
The <livewire:pulse.exceptions /> card shows the frequency and recency of exceptions occurring in your application. By default, exceptions are grouped based on the exception class and location where it occurred. See the exceptions recorder documentation for more information.
The <livewire:pulse.queues /> card shows the throughput of the queues in your application, including the number of jobs queued, processing, processed, released, and failed. See the queues recorder documentation for more information.
The <livewire:pulse.slow-requests /> card shows incoming requests to your application that exceed the configured threshold, which is 1,000ms by default. See the slow requests recorder documentation for more information.
The <livewire:pulse.slow-jobs /> card shows the queued jobs in your application that exceed the configured threshold, which is 1,000ms by default. See the slow jobs recorder documentation for more information.
The <livewire:pulse.slow-queries /> card shows the database queries in your application that exceed the configured threshold, which is 1,000ms by default.
By default, slow queries are grouped based on the SQL query (without bindings) and the location where it occurred, but you may choose to not capture the location if you wish to group solely on the SQL query.
If you encoun