What this prompt does
This prompt makes the AI set up Laravel Pulse monitoring for an app handling [traffic_volume] on [infrastructure] with [database_type], on Laravel [laravel_version]. It configures the [storage_method] driver, sets [retention_period] and [sample_rate], enables built-in recorders with thresholds like [slow_query_threshold] and [slow_request_threshold], and builds [custom_card_count] custom cards. Declaring traffic volume up front is what pushes the AI toward sampling and a separate database rather than a setup that buckles under load.
The structure works because production monitoring lives in its specifics. The [primary_card] and [additional_cards] capture business metrics next to slow queries; [dashboard_sections] and [authorized_roles] organize and gate the dashboard; [alert_count] rules fire on [alert_conditions] through [notification_channels] with an [alert_cooldown] to prevent fatigue. The production-optimization step uses [ingest_method], an optional [separate_db], aggregation, and a [purge_schedule], plus a post-deploy health check comparing metrics over [comparison_window]. Each custom card is built as a trio — a Livewire component, a recorder class that captures the metric, and a view — so business signals and infrastructure data share one dashboard. The [infrastructure] and [database_type] you declare shape the ignore patterns and recorder thresholds, and the aggregation step rolls detailed records into hourly and daily summaries so the storage table stays manageable at sustained traffic.
When to use it
- Your app is in production and you want to see what is actually slow
- You need slow-query and slow-request detection without a heavy external APM
- You want business metrics like revenue-per-minute beside infrastructure cards
- You need alerting on response time, error rate, or queue backlog with cooldowns
- You run real traffic and must sample and isolate monitoring data to limit overhead
- You want a post-deployment health check that flags regressions automatically
Example output
The AI returns Pulse configuration with [storage_method], [retention_period], and [sample_rate], enabled recorders with your thresholds and ignore patterns, custom card triads (Livewire component, recorder class, view) including [primary_card], a role-gated dashboard organized into [dashboard_sections], [alert_count] alert rules wired to [notification_channels], a production setup with buffered ingest and an optional dedicated Pulse database, and a deployment health check comparing p95, error rate, and cache hit rate before and after release.
Pro tips
- Set
[sample_rate]below 1.0 at high[traffic_volume]— recording every request is what makes naive Pulse setups expensive - Use
[separate_db]when traffic is real so Pulse writes do not contend with application queries - Tune
[slow_query_threshold]to your baseline; too low and the dashboard drowns in noise - Add an
[alert_cooldown]from the start — alert fatigue kills the value of monitoring fast - Put real business metrics in
[primary_card]so the dashboard is something you watch after every deploy - Schedule
pulse:purgevia[purge_schedule]so retention actually holds and the table does not grow unbounded
