Appearance
Laravel Telescope in production — only the slow and failed requests, with everything they ran
Telescope is the best answer Laravel has to "what exactly happened in that request". It writes down each request with its input and answer, every database query with the line that ran it, each queued job with its data, each exception with its stack trace. You open one entry and see the whole story.
On a live site it is usually switched off, for three reasons. Out of the box nobody may open it outside local until someone writes the gate. Left as it is, it records every request and every query, and the table grows by hundreds of megabytes a day. And on a CMS most of what it records is noise: the admin polling itself, the toolbar's calls, pages served from the cache. Every page of the site also goes through one route, so the list says /{any} where you want to know "the category page".
kitloom/telescope keeps Telescope on in production and makes it answer the question you have.
Ask the agent
With kitloom/ai connected, an agent whose user may open Telescope calls telescope_report:
- "What broke on the site since yesterday?"
- "Which pages were slowest this afternoon, and what queries made them slow?"
- "Did any queued job fail overnight?"
It gets exceptions grouped by class and line with how often, the slowest requests with their path, status and page template, failed jobs with their module and error, and slow queries grouped by shape. It never gets request bodies, headers, sessions, emails or job data, and the values in a query come back as ?. The agent then looks at the module that runs the query, or tells you which page to open, with exactly the rights its key gives it. How to connect one: Run your site from Claude or Cursor.
What it keeps
On local, everything Telescope records. On the live site, what Telescope → Settings asks for:
| Kept | How |
|---|---|
| A request slower than Slow request (1000 ms by default) | With everything recorded during it: queries, models, views, cache, events |
| A request that answered 4xx or 5xx | The same |
| An exception | With the request or job it was thrown in |
| A query slower than Slow query (100 ms) | With the request or job that ran it |
| A queued job, a scheduled task, an outgoing HTTP call, a notification | Each alone |
A slow page comes with the queries that made it slow, not as one lonely line. Never recorded: a page the page cache answered, Livewire's polling of the admin, the admin bar's own calls, files served through PHP, Telescope itself. Record everything turns the filter off while you look into something; turn it off again afterwards.
Find a page by its template
Telescope tags entries so its search can find them. kitloom adds the names a CMS needs:
template:single-product,template:taxonomy-product_cat,template:search,template:404— the template the page was drawn with, the way WordPress's template hierarchy names it;post:12,term:5,user:7— the record the page shows;module:bookings,module:webhooks— on a job, a notification or an email of a kitloom module.
"The dried fruit category is slow" becomes template:taxonomy-product_cat in the search box, one click on the request, and the Queries tab saying how many of its queries were repeated.
Secrets stay out
Telescope stores what a request sent. The module hides passwords, tokens and cookies by name, and also anything whose name looks like a secret — smtp_pass, api_key, x-api-key, ?token= — in the site's own requests, in settings saved from the admin, and in calls to other services. Names, emails and form fields are stored as sent; that is why only users with Open the Telescope dashboard (view_telescope, administrators from the start) get in, in every environment.
It looks after itself
telescope:prune runs every night with the hours of Keep entries (48 by default). The migration runs from the package with the site's table prefix, so telescope:install is not needed; the dashboard's styles and scripts come from the package too. The admin's Telescope section has a badge that says whether it records, is paused, is off in the environment (TELESCOPE_ENABLED=false), or still waits for php artisan migrate. Emails are left to the Emails module, which keeps them with their text.
Telescope, Pulse, Horizon, Emails
| Module | Shows | For |
|---|---|---|
| Telescope | Each recorded request, query, job and exception, one by one | Why one thing went wrong or was slow |
| Pulse | Totals and averages: slowest pages, queries, jobs, servers | How the site does in general |
| Horizon | The workers of a queue on Redis | Running the queue |
| Emails | Every email sent, with its body | What a customer received |
Telescope sees jobs on any queue, the database queue included.
For a Laravel developer
It is laravel/telescope 5 as it is; the module adds hooks. A batch filter (Telescope::filterBatch) decides per request or job, so a problem keeps its context and an ordinary page leaves only the entries asked for one by one; the decisions are Kitloom\Telescope\Recording, and the settings are read at each decision, never written into telescope.* config, so config:cache and Octane are safe. kitloom-telescope.filter set to false leaves recording to your own filters, kitloom-telescope.authorize to your own Telescope::auth(). The tags listen to kitloom/site's MainQueryResolved event. Everything is in the guide.
Watch it
Try it
Open a sandbox in one click, with no sign-up: Filament or Nova. Every detail of the module is in the Telescope guide.