Before you start
- Inventory what you currently use Sentry for — errors, performance, releases, session replay, front-end JS?
- NightOwl covers: errors, performance, queries, queues, scheduled tasks, cache, mail, notifications, outgoing HTTP, logs (all backend-only)
- NightOwl does not cover: front-end JavaScript source maps, session replay, cross-service distributed tracing without OTel
- Provision a PostgreSQL instance (or reuse existing) — NightOwl creates its own prefixed tables
Migration timeline
Install NightOwl
composer require nightowl/agent, then php artisan nightowl:install. Both SDKs now active — no conflict.
Reconfigure alert channels
Recreate Slack, Discord, Email, Webhook in NightOwl's alert channels UI. Keep Sentry channels active for now.
Parallel run (1-2 weeks)
Compare what shows up in each. Validate NightOwl catches the same errors. Check your team can navigate the new UI.
Disable Sentry alert channels
Suppress the duplicate notifications so your team isn't getting paged twice per incident.
Remove Sentry SDK
composer remove sentry/sentry-laravel, delete config/sentry.php, remove SENTRY_LARAVEL_DSN env var. Deploy.
Cancel Sentry subscription
If Laravel is your only Sentry usage. Keep if you still need front-end JS tracking.
Parallel install — both SDKs together
# Keep your existing Sentry config untouched. Add NightOwl alongside:
composer require nightowl/agent
php artisan nightowl:install
# Follow the prompts to configure your PostgreSQL connection and NightOwl account.Both SDKs register independent exception handlers. No conflict — exceptions are reported to both destinations simultaneously. This is the parallel validation period.
What to validate during parallel run
- Exception coverage — every exception Sentry sees should also land in NightOwl. Compare issue counts in both.
- Performance data — check that slow routes, slow queries, and queued jobs appear with similar data shape.
- Alert delivery — trigger a controlled error in staging. Both Sentry and NightOwl should page.
- Team workflow — does NightOwl's issue-management UI fit how your team triages? (Status, priority, assignment, comments are all there.)
Removing Sentry cleanly
composer remove sentry/sentry-laravel
rm config/sentry.php
# In .env — delete these:
# SENTRY_LARAVEL_DSN=...
# SENTRY_TRACES_SAMPLE_RATE=...
# Remove Sentry references from:
# - App\Exceptions\Handler (if you added Sentry integration)
# - Any custom exception reporters
php artisan config:clear
php artisan cache:clearWhat you'll want Sentry for (still)
- Front-end JS errors with source maps — NightOwl doesn't do browser-side.
- Mobile app crash reporting — NightOwl doesn't do iOS / Android SDKs.
- Session Replay — Sentry-specific product, no NightOwl equivalent.
- Cross-language distributed tracing — Sentry's SDK suite propagates traces across polyglot stacks natively. For pure Laravel, NightOwl's per-request traces cover the same ground within one app.
AFTER MIGRATION
Flat from-$5/mo instead of Sentry's event-based bill
Telemetry lives in your PostgreSQL. No per-event pricing, no per-seat fees, no surprise traffic-spike bills. The exception your team chased all night doesn't cost you extra this month.