[ MIGRATION ]

Migrate from Laravel Telescope to NightOwl

Keep Telescope for dev. Use NightOwl for production. Each is excellent at its stage.

QUICK ANSWER

How do I migrate from Telescope to NightOwl?

Keep Telescope installed — it's unmatched for local debugging. Disable it in production (TELESCOPE_ENABLED=false in production .env) and install NightOwl to replace its production role. NightOwl writes telemetry asynchronously via a separate agent process, so it doesn't add request latency like Telescope's synchronous DB writes do. Drop telescope_* tables once you're certain nothing queries them.

Updated · 2026-04-13

Why this migration exists

Telescope is a world-class Laravel debugger. Teams install it for local dev, it works beautifully, and some of them leave it on in production because no one stops them. That's where the problems start:

  • Synchronous DB writes on every request add 10-50ms
  • Storage bloats fast — millions of telescope_entries rows/day
  • No aggregation, no alerts, no team triage workflow
  • Often exposed publicly because /telescope lacks auth by default

NightOwl replaces Telescope's production role. Keep Telescope where it shines — in dev.

Step 1 — install NightOwl

bash
composer require nightowl/agent
php artisan nightowl:install

Step 2 — disable Telescope in production only

In production .env

bash
TELESCOPE_ENABLED=false

Or condition the service provider registration on environment:

bootstrap/providers.php

php
return [
    App\Providers\AppServiceProvider::class,
    // Only load Telescope locally
    ...(app()->environment('local', 'staging') ? [
        App\Providers\TelescopeServiceProvider::class,
    ] : []),
];

Step 3 — verify Telescope is off in production

bash
# On a production server:
php artisan route:list | grep telescope
# Should return empty if Telescope is properly disabled.

# Double-check the /telescope route is inaccessible:
curl -I https://yourapp.com/telescope
# Should return 404.

Step 4 — drop Telescope's tables (optional)

Once you're certain nothing queries the Telescope tables in production:

sql
-- Back up first if you want the historical archive
\copy telescope_entries TO '/tmp/telescope_entries.csv' WITH CSV;

-- Then drop
DROP TABLE telescope_entries_tags;
DROP TABLE telescope_entries;
DROP TABLE telescope_monitoring;

Frees storage and removes the background burden of Telescope's prune job.

Keep using Telescope in dev

Your local .env keeps TELESCOPE_ENABLED=true. The per-request inspector at /telescope stays available locally and in staging. Telescope is unmatched for this use case — there's no reason to remove it.

What each tool owns now

Environment Use Why
Local devTelescopeUnmatched per-request inspector
StagingBothTelescope for debugging, NightOwl for pre-prod validation
ProductionNightOwlAsync, aggregated, alerted, BYOD Postgres

AFTER MIGRATION

The right tool for each stage

Telescope for the detail view locally. NightOwl for aggregation, alerts, and production-safe telemetry. Each excellent at its role.

INSTALL

Install in 60 seconds

Works on Laravel 10+ / PHP 8.2+. Keep the official Nightwatch package — NightOwl reads the same instrumentation.

$ composer require nightowl/agent
$ php artisan nightowl:install

Publishes the config, creates monitoring tables in your PostgreSQL, and starts the agent. First payload lands in the dashboard within 30 seconds.

Frequently asked questions

Should I remove Laravel Telescope when I install NightOwl?

Only in production. Keep Telescope installed for local/staging — it's unmatched for development debugging. What you remove is the production deployment of Telescope, which was never a great idea (writes inline to your DB, bloats storage, lacks aggregation). NightOwl replaces Telescope's production role; Telescope keeps its development role.

How do I disable Telescope in production only?

Set TELESCOPE_ENABLED=false in your production .env. Or condition the TelescopeServiceProvider registration on environment in config/app.php. Your dev/staging environments keep working.

Can NightOwl give me Telescope-like request inspection?

Yes — NightOwl's request detail view shows every query, cache call, outgoing HTTP, and event fired during a request, similar to Telescope's per-request inspector. The difference: NightOwl's data is asynchronous (production-safe) and aggregated across traffic, while Telescope is synchronous (dev-friendly but slow at scale).

Can I delete the Telescope tables after installing NightOwl?

Yes, if you've disabled Telescope everywhere. The tables (telescope_entries, telescope_entries_tags, telescope_monitoring) can be dropped once you're certain nothing queries them. NightOwl writes to its own nightowl_* tables; they don't overlap. Back up the tables before dropping if you want a historical archive.

Do I need to migrate Telescope entries to NightOwl?

No. Telescope's schema is request-inspector-oriented, not production-APM-oriented. The data shapes don't align cleanly. Let NightOwl start fresh. Keep the Telescope tables around for a month if you want historical reference, then drop them.

Will my development workflow change?

Barely. Keep Telescope installed locally — you still get the per-request inspector at /telescope in dev. In production, the NightOwl dashboard is where you look for exceptions, slow queries, failed jobs. Different tools for different stages.

Does NightOwl slow down requests like Telescope does?

No. NightOwl buffers telemetry via a separate ReactPHP agent process — request-path overhead is under 1ms. Telescope writes synchronously to your DB during the request, which adds 10-50ms at volume. That's the core reason Telescope isn't production-ready; NightOwl fixes it architecturally.

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

Related