Laravel Telescope Dashboard Laravel Package

Getting Started

wamesk/laravel-telescope-dashboard is a UI layer on top of laravel/telescope — it gives you a curated dashboard (stats/charts plus filtered, human-readable views of Telescope entries) instead of Telescope's own raw entry list. It does not replace Telescope; Telescope still records everything.

Minimal setup:

1. Install Telescope first and run its migrations — the dashboard reads Telescope's tables directly, so an empty telescope_entries table means an empty dashboard.
2. composer require wamesk/laravel-telescope-dashboard
3. Publish the config and assets (check php artisan vendor:publish output for the package's tags; typically one tag for config, one for public assets — the frontend assets are required, unlike Telescope's own compiled assets).
4. Open the published config and confirm the route prefix, middleware, and authorization gate.
5. Visit the dashboard route (default /telescope-dashboard in a fresh install) as an authenticated user who passes the gate.

Where to look first:

• config/telescope-dashboard.php (or similarly named) — route, middleware, gate/authorization callback, and any pruning/retention settings.
• The dashboard's landing page — the stat cards give you the fastest read on whether the package is wired to the right Telescope data at all. If cards are zeros but Telescope's own /telescope shows entries, the problem is config/connection, not the package.

First use case: point the dashboard at staging and use it as the "what is this app actually doing" screen — slow requests, failed jobs, outgoing HTTP calls — without giving the whole team full Telescope access.

Implementation Patterns

Two-window workflow. Keep /telescope available for deep inspection and use this dashboard for daily triage. The dashboard is an entry point ("something is slow/failing — which request, which user, which client?"); you then jump to Telescope for the full payload, stack trace, or request headers. Don't try to make this package your only Telescope surface.

Authorization is the main integration point. Gate the route to a role (admin, on-call) rather than "any authenticated user," and drive that from the published config so it's environment-aware. A common pattern is: full access in local/staging, gate-restricted in production.

Client Requests triage (new in 1.6.0). The Client Requests view now carries a user column and a user filter, so outgoing HTTP calls can be attributed to the user whose request triggered them. Day-to-day this turns the page into a per-customer debugging tool: filter by user, see which third-party endpoints that user's requests hit, and spot a single tenant hammering an integration or receiving errors from one provider. Use it when a bug report is user-specific ("checkout fails for this account") and you suspect an external API rather than your own code. Two caveats in practice: entries recorded before 1.6.0 or from queue workers/console commands have no user context, so they won't match a filter; and the attribution is the authenticated user at the time of the outgoing call, not the originator of a queued job.

Pair with Telescope's pruning config. Telescope's TELESCOPE_* retention settings govern what the dashboard can show. If you want a longer history for trend cards than for raw entries, that's not something this package solves — it's a Telescope config/telescope_entries question.

Environment scoping. Treat the dashboard as a non-production tool by default, or as a production tool with strict gating. It's read-mostly, but it exposes request payloads, headers, and potentially sensitive client-request URLs/bodies to whoever can reach the route.

Team onboarding. Because it's a read-only view over standard Telescope data, it's a low-risk way to give product/support engineers visibility without teaching them Telescope's filter syntax. Document the dashboard URL and the gate in your onboarding notes.

Gotchas and Tips

• It is not a Telescope replacement. Uninstalling Telescope, disabling its watchers, or clearing telescope_entries breaks the dashboard. Keep Telescope installed and recording; only the UI is being swapped out.
• Assets must be published and rebuilt on upgrade. After composer update, re-publish/clear cached assets (php artisan vendor:publish --force for the package tag, then php artisan view:clear / config:clear). A stale compiled asset bundle after an upgrade is the usual cause of "the new user column/filter doesn't appear" on 1.6.0.
• Empty dashboard ≠ broken package. Check in order: Telescope migrations ran, TELESCOPE_ENABLED=true, entries exist in telescope_entries, and the dashboard is pointed at the same DB connection. A separate Telescope connection is a frequent miss.
• Route/gate config is cached. If you change the gate callback or route prefix and nothing happens, you edited config under a cached config (php artisan config:cache in production).
• Authorization is opt-in-ish. Verify the default gate rather than assuming the route is locked down; explicitly define who may view it. This is the single most important config change for production use.
• User attribution has gaps by design. Console commands, queue workers, and scheduled tasks have no authenticated user, so they appear without a user and won't be returned by the user filter. Don't file that as a bug — plan around it when triaging background HTTP traffic.
• Performance on large tables. Filtering and stat cards query telescope_entries; with an unpruned millions-row table, dashboard pages get slow. Keep Telescope's pruning enabled and index-friendly retention windows.
• Extension point: the config file and the authorization callback are the intended customization surfaces for most needs. Deeper UI changes mean overriding published views/blade components — expect those to conflict on upgrade, so keep customizations minimal and recorded.
• Version pinning. This is a small, actively iterated package (1.6.0 is a feature-level minor release adding a filter/column rather than a breaking change). Pin a minor version in composer.json and read the changelog on each bump; view/config publishes can drift between minors.