What is Laravel Telescope, how do you install it, and how do you register it so it runs only on local machines?
answer
- records requests, queries, jobs, mail
- telescope:install then migrate
- dashboard at /telescope
- --dev plus environment('local') check
- remove from bootstrap/providers.php
basics
~20 sTelescope is a first-party dashboard that records requests, queries, jobs, exceptions, logs and mail into database tables. Install it, run telescope:install and migrate, and open /telescope; for local-only use, install with --dev and register its providers only in local.
solid answer
~30 sLaravel Telescope stores **entries** (requests, queries, jobs, exceptions, log lines, mail, notifications, cache calls, scheduled tasks, dumps and more) in database tables and shows them in a dashboard at `/telescope`. Install with `composer require laravel/telescope`, then `php artisan telescope:install`, which publishes `App\Providers\TelescopeServiceProvider`, `config/telescope.php` and the migrations and adds the provider to `bootstrap/providers.php`, then `php artisan migrate`. For local-only use: install with `--dev`, remove the provider from `bootstrap/providers.php`, and in `AppServiceProvider::register()` register both `Laravel\Telescope\TelescopeServiceProvider` and your own provider only when `$this->app->environment('local')` and the class exists. Finally stop Composer auto-discovering the package, so production, installed without dev packages, never loads it.
code
php · 17 lines<?php
namespace App\Providers;
use Illuminate\Support\ServiceProvider;
class AppServiceProvider extends ServiceProvider
{
public function register(): void
{
if ($this->app->environment('local')
&& class_exists(\Laravel\Telescope\TelescopeServiceProvider::class)) {
$this->app->register(\Laravel\Telescope\TelescopeServiceProvider::class);
$this->app->register(TelescopeServiceProvider::class);
}
}
}go deeper
Know that Telescope records requests, queries, jobs and exceptions for later inspection, that it installs with telescope:install plus migrate, and that the dashboard lives at /telescope.
Explain what telescope:install publishes and registers, how entries are grouped by batch, and the steps of local-only registration.
Justify local-only as the default, and know the switches for disabling or pausing recording without a deploy.
Decide per environment whether recorded request history is worth its storage, performance and data-exposure cost, and write that down as policy.
## What Telescope is **Laravel Telescope** is a first-party package that records what your application does and shows it in a web dashboard. Each recorded item is an **entry** with a type: request, command, schedule, job, batch, exception, log, dump, query, model, event, mail, notification, gate, cache, redis, view or HTTP client request. Entries from the same request, command or job share a **batch id**, so opening a request shows every query, event and log line it produced. Entries are collected in memory while the request runs and written to the database in one go when the application terminates, after the response has been sent (and after each queued job finishes); collecting and storing them still costs work in every process. ## Standard installation ```bash composer require laravel/telescope php artisan telescope:install php artisan migrate ``` `telescope:install` does four things: 1. publishes `app/Providers/TelescopeServiceProvider.php`, the place for filters, tags, hidden fields and the `viewTelescope` gate; 2. publishes `config/telescope.php`, which lists every watcher and its options; 3. publishes the migration that creates `telescope_entries`, `telescope_entries_tags` and `telescope_monitoring`; 4. adds `App\Providers\TelescopeServiceProvider` to `bootstrap/providers.php`. After `migrate`, the dashboard is at `/telescope` (the `path` option, `TELESCOPE_PATH`). By default only the `local` environment can open it; other environments go through the `viewTelescope` gate. ## Local-only registration Telescope is described in the docs as a companion to **local development**. To make sure it can never run on a server: 1. Install it as a dev dependency: `composer require laravel/telescope --dev`. 2. Run `telescope:install` and `migrate` as usual. 3. Remove `App\Providers\TelescopeServiceProvider` from `bootstrap/providers.php`. 4. Register both providers conditionally in `AppServiceProvider::register()` (see the example below). Skipping step 3 is not an option: your `App\Providers\TelescopeServiceProvider` extends a Telescope class, so a production install without dev packages would fail to boot with that provider still listed. The `class_exists` check matters because production installs skip dev packages, so the class is missing there. 5. Add `laravel/telescope` to the `dont-discover` list in `composer.json`, so package auto-discovery does not register the package provider on its own. | Setup | Loaded in production? | Tables needed in production? | |---|---|---| | Standard install | yes, gated by `viewTelescope` and filters | yes | | Local-only install | no; class missing and environment check fails | no, but the migration still exists, so the tables are created anyway unless you move it | ## Turning it off without uninstalling - `TELESCOPE_ENABLED=false` makes the package provider skip booting routes and recording. - Each watcher has its own switch, for example `TELESCOPE_QUERY_WATCHER=false`. - `php artisan telescope:pause` and `telescope:resume` stop and restart recording without a deploy; `telescope:clear` deletes all entries. ## Reading what it recorded The dashboard has one screen per entry type, each with search and tag filters. Opening an entry shows its details plus the rest of its batch: - a **request** lists its queries, models, events, cache calls, logs and views, along with headers, payload, session and response; - a **job** shows its payload, status, attempts and the entries produced while it ran; - an **exception** shows the trace, the line of code, and the request or job it happened in. Because entries are stored, you can inspect a request that happened minutes ago, including one triggered by a teammate, a webhook or a queued job, which in-page tools cannot show. ## Why interviewers ask The question checks whether you know Telescope exists as the Laravel way to see queries, jobs and exceptions after the fact, and whether you treat it as a development tool first. The strongest answers mention the local-only pattern unprompted, because a Telescope dashboard left open on a public server exposes request data, sessions and SQL.
- Why does the local-only registration check class_exists() as well as the environment?With Telescope installed via `--dev`, a production `composer install --no-dev` does not install the package, so referencing `Laravel\Telescope\TelescopeServiceProvider` there would fail. The `class_exists` guard keeps the code safe wherever dev packages are absent, even if an environment is misconfigured as `local`.
- Telescope records nothing while you run php artisan queue:work, yet jobs do appear. Why?Telescope skips recording for some long-running or noisy commands, including `queue:work`, `queue:listen` and the Horizon commands, so the worker command itself is not an entry. It starts recording again for each job when the job begins processing and stores that job's entries when it finishes.
saying these in an interview costs you the question
- Telescope only shows data while you watch it live, like a toolbar.
- telescope:install creates the tables without running migrate.
- Installing with --dev is enough on its own to keep it out of production.
- Telescope needs Redis to store its entries.
- The dashboard is public in every environment unless you add middleware.