[ GLOSSARY ]

Laravel Telescope in production — the honest answer

QUICK ANSWER

Can I run Laravel Telescope in production?

Technically yes, practically no for anything beyond a tiny app. Telescope writes every request, query, job, and cache event synchronously into your database — which at any real traffic bloats storage, slows requests, and gives you no aggregation or alerting. It's a debugger, not a monitoring tool. Use Laravel Nightwatch Cloud, NightOwl, or a dedicated APM instead.

Updated · 2026-06-04

Telescope is one of the best things about developing in Laravel and one of the worst things you can leave running in production, and the gap between those two facts catches a lot of teams out. The short version: it's a debugger, not a monitor. The longer version is worth understanding so you know exactly where the line sits and what to do if you've already crossed it.

What Telescope is designed for

Telescope is Laravel's official development debugger — a first-party package for inspecting requests, queries, jobs, cache events, and more during development and in staging. It's excellent at that job.

Production is a different problem. You don't need a per-request inspector with full payloads; you need aggregated views across thousands of requests per minute, long-term trending, grouped exceptions, and alerts when things regress.

Why it hurts in production

  • Synchronous DB writes — every request writes ~10-30 rows to telescope_entries before returning. 10-50ms added to each request.
  • Storage explosion — 1,000 req/min at 20 entries each = 28.8 million rows/day. Telescope's prune command helps but your primary DB shouldn't be a telemetry store.
  • No aggregation — no p95 per route, no fingerprint-grouped exceptions, no failure-rate trending. You inspect individual requests, not patterns.
  • No alerting — Telescope shows errors but won't page you.
  • No retention policy — besides manual pruning.
  • No auth by default — /telescope is open unless you add middleware. Easy to forget.

If you're going to run it in production anyway

Low-volume apps (under ~100 req/min) sometimes get away with it. Minimum protections:

app/Providers/TelescopeServiceProvider.php

php
public function register(): void
{
    parent::register();

    // Sample — record 10% of requests in production
    Telescope::filter(function (IncomingEntry $entry) {
        if ($this->app->environment('local')) return true;
        if ($entry->isReportableException()) return true;
        if ($entry->isFailedRequest()) return true;
        if ($entry->isFailedJob()) return true;
        return rand(1, 100) <= 10;
    });

    // Redact any sensitive request fields
    Telescope::hideRequestParameters(['password', 'password_confirmation', 'credit_card']);
    Telescope::hideRequestHeaders(['authorization', 'cookie', 'x-api-key']);
}

Lock /telescope behind auth middleware. Schedule telescope:prune --hours=48 hourly. Move telescope_entries tables to a separate database connection if you can. These mitigations make it tolerable, not good.

The alternatives

Most teams land on: Telescope locally and in staging (brilliant for that) + a dedicated APM in production.

RELATED

Frequently asked questions

Can I run Laravel Telescope in production?

Technically yes — it installs and works. Practically no for anything beyond a tiny app. Telescope writes every event (requests, queries, cache, jobs, mail) synchronously into your database during the request. At any real traffic that bloats your DB, slows every request, and gives you no aggregation, alerting, or retention management. It's designed for local and staging debugging, not production monitoring.

What's wrong with using Telescope in production?

Three issues. Performance: synchronous writes to the DB per request add latency and contention. Scale: a busy app generates millions of telescope_entries rows per day, which blow out your DB storage. Features: no grouping, no trending, no alerts, no team-friendly issue management. Also no authentication by default — you must protect /telescope behind auth middleware yourself.

If Telescope isn't production-ready, what should I use?

Laravel Nightwatch Cloud (official first-party, free under 300K events/month), NightOwl (BYOD PostgreSQL dashboard from $5/month flat), or a generic APM like Sentry or Inspector. All three do what Telescope does for production scale — aggregation, alerting, retention policies, team workflows — without writing synchronously into your request path.

Is there a way to make Telescope production-safe?

You can sample (record only 1% of requests via Telescope::filter), redact PII, and lock /telescope behind strict auth — and plenty of teams do. It's still only a debugger in production; you're not getting aggregate views, alerting, or the team collaboration features you'd expect from a real monitoring product. For emergency debugging on a low-traffic app, sampled Telescope works. For a production monitoring layer, use a dedicated tool.

How is Telescope different from NightOwl?

Telescope writes telemetry into your primary DB inline with requests and gives you a per-request inspector. NightOwl ships data out-of-process via the Nightwatch agent into a separate PostgreSQL and gives you aggregated production dashboards — exception grouping, query pattern p95, queue failure rate, alert channels. Different tools for different jobs. Many teams run Telescope locally and NightOwl in production.

Does Telescope impact request performance?

Yes. Telescope's inline writes add 10-50ms per request depending on how many watchers are active and how busy your DB is. That's invisible in dev; at 1,000 req/min in production it compounds into real degradation and extra DB load. The Nightwatch package (used by Nightwatch Cloud and NightOwl) buffers telemetry in a separate agent process — zero request-path overhead.

How do I uninstall Telescope from production safely?

Remove telescope:prune from your scheduler, remove the TelescopeServiceProvider from config/app.php (or set TELESCOPE_ENABLED=false), drop the telescope_entries and telescope_entries_tags tables after you confirm nothing is querying them, and remove laravel/telescope from composer.json. Deploy and monitor — DB load should drop immediately.

PRICING

Flat pricing. No event caps. No per-seat fees.

14-day free trial, no credit card. Your PostgreSQL, your data.

HOBBY

$5 /month

1 app · 14 days lookback · all Laravel events

TEAM

$15 /month

Up to 3 connected apps · unlimited environments · all Laravel events

AGENCY

$69 /month

Unlimited apps · unlimited agent instances · same flat rate at any traffic

Start 14-day free trial See full pricing