Laravel Telescope: a debug assistant that records requests, queries and jobs

What Laravel Telescope records that your log file does not

A Laravel application produces a lot of runtime information, and most of it disappears the moment the request finishes. The log file keeps what you explicitly wrote, the database keeps what you persisted, and the queue table keeps a job's status. Nothing keeps the shape of the request itself. The README lists what Telescope captures: requests coming into your application, exceptions, log entries, database queries, queued jobs, mail, notifications, cache operations, scheduled tasks and variable dumps. That list is the product. Instead of scattering Log::info calls through a controller to find out which query ran and in what order, you open the Telescope interface and read the recorded entries for that request. The README describes it as a companion to your local Laravel development environment, and that framing matters for who should install it. This is a development tool first. If you are debugging a slow endpoint on your own machine, Telescope is aimed at you. If you are looking for uptime alerting or a dashboard your on-call engineer opens at 3am, the README does not present Telescope as that.

How the watchers, storage and dashboard fit together

The repository layout shows the mechanism. There is a src directory holding the package code, a config directory holding the published configuration, a database directory holding migrations, a routes directory, and a resources directory with the frontend that the package.json builds through Vite. The package.json shows a Vue 2 frontend with vue-router, axios, highlight.js, sql-formatter and vue-json-pretty as build dependencies, which tells you the dashboard is a client-side application reading data from Laravel routes rather than server-rendered Blade pages. The database directory and its migrations tell you the other half: recorded entries are persisted, not held in memory, which is why a config file exists to control what gets stored. The practical consequence is that Telescope writes to your database as your application runs. Every recorded request, query and job is a row. On a busy local environment that adds up, and the config file is where you decide which watchers are on. The README does not enumerate the config keys, so treat the published config file as the authority and read it before assuming a watcher is free.

Installing Telescope and recording your first request

The README does not carry install steps. It points to the Laravel website at https://laravel.com/docs/telescope for documentation, and the package is published on Packagist as laravel/telescope, so Composer is the install path. The README gives no commands, so the only thing that can be stated without inventing flags is the package name and where the documentation lives. There is no code block here for that reason: every command in this section would be a guess.

What the repository does show is what you end up with after setup. There is a config directory for the published configuration, a database directory for the migrations, and a resources directory with the Vue frontend that package.json builds through Vite. The published configuration file is the place to look next, because it controls which watchers are active and the README does not list those keys. Read the file itself rather than guessing at names. If you are working on the package rather than consuming it, the repository has a workbench directory and a testbench.yaml, which is how the package boots a Laravel application for its own tests.

Where Telescope is the wrong tool

The README's own sentence is the limitation: Telescope makes a wonderful companion to your local Laravel development environment. That is a scope statement, not marketing filler. A tool that persists recorded requests, queries and jobs into your database is expensive to run against production traffic, and the README does not describe a retention policy, a sampling mechanism or a data expiry command. It also does not document rollback. If you deploy it and decide the write volume is unacceptable, removing it means dropping the tables its migrations created and removing the published config, and the README does not walk you through that. There is a second boundary worth naming. Telescope records; it does not alert. Nothing in the README mentions thresholds, notifications on error rate, or integration with an incident tool. If your problem is knowing that something broke in production, Telescope is not the instrument, and installing it will not get you there. The UPGRADE.md file in the repository root is the signal that the package's own internals change between major versions, so a version bump is not a no-op.

Telescope against an external application performance monitor

The real alternative for a Laravel team is an external application performance monitoring service, and the difference is architectural rather than cosmetic. An external monitor ships data off the machine to a hosted backend and is designed to run continuously against production traffic, with sampling and retention handled on the vendor side. Telescope keeps everything inside your application: the watchers run in your process, the entries land in your database, and the dashboard is served by your own routes. That is why it is cheap to start and why it is a poor fit for production scale. The trade-off runs the other way too. An external service gives you a query interface over weeks of history and alerting on top of it, but it cannot show you a variable dump from the code path you just edited, because it was not built to instrument a single local request. Telescope can, and it does so without a network round trip or an account. For local work, the in-application model is the advantage. For anything that outlives your laptop, it is the constraint.

Licence, upgrade cost and the 5.x branch

Telescope is released under the MIT licence, stated in the README and in the LICENSE.md file at the repository root. MIT permits commercial use, modification and redistribution with the licence and copyright notice preserved. That is a permissive licence and it does not impose copyleft obligations on your application, but it is not legal advice and your organisation's own review process decides what it accepts. On upgrades, the repository carries an UPGRADE.md file alongside the CHANGELOG.md, which is the maintained record of what changes between versions. The default branch is 5.x and the most recent release listed is v5.25.0, published on 2026-09-22, with v5.24.0 on 2026-09-08 and v5.23.0 on 2026-09-01 before it. The last push to the repository was on 2026-09-22. The upgrade cost is not zero because the published config file is part of your application once it is published: a new version can add config keys, and your existing published copy will not have them until you republish or merge. Read UPGRADE.md before bumping the constraint in composer.json.

Editorial conclusion

Adopt Telescope when you are working on a Laravel application locally and want a single screen that shows requests, exceptions, log entries, database queries, queued jobs, mail, notifications, cache operations, scheduled tasks and variable dumps without adding logging calls by hand. Skip it when you need long-term production observability, because the README frames it as a companion to your local development environment and says nothing about retention or sampling policy. Before you install, verify the PHP and Laravel versions required by the 5.x branch and read UPGRADE.md for the upgrade path from the version you are on.

Frequently asked questions

Official sources

1. laravel/telescope on GitHub
2. License: MIT
3. Project website
4. README
5. Releases