It can be, if you control who opens the dashboards. Telescope records requests, queries and exceptions, and Horizon shows queue activity. By default both dashboards are gated outside the local environment, but you must define who passes the gate. Review the gate, limit retention, and keep Telescope off if you do not need it.
What each tool exposes
Telescope is a debugging assistant. It records requests, exceptions, queries, jobs and more, so its entries can hold request data you would not want broadly visible. Horizon is a dashboard and configuration layer for Redis queues, showing jobs, throughput and failures.
Both give an authenticated viewer a deep look inside your app. That is useful for you and valuable to anyone who gets in.
How the gates work
The Telescope docs say the dashboard is at /telescope, and that by default you can only access it in the local environment. In TelescopeServiceProvider there is a viewTelescope gate that controls access in non-local environments. Horizon has a similar dashboard authorization step in its documentation.
A gate typically looks at the signed in user:
Gate::define('viewTelescope', function (User $user) {
return in_array($user->email, ['ops@example.com']);
});
Keep the list short, tie it to roles you manage, and prefer a role check over a hard coded email when your team grows.
Review checklist
| Question | What good looks like |
|---|---|
| Is the dashboard reachable in production at all? | Only if you have a reason |
| Who can pass the gate? | A named, small group |
| Is it behind login and, where possible, a VPN or IP limit? | Yes |
| How long are entries kept? | Pruned on a schedule |
| What request data is recorded? | Sensitive fields hidden |
Retention and data
The Telescope docs warn that without pruning, the telescope_entries table accumulates records very quickly, and recommend scheduling telescope:prune daily. Pruning also shortens how long sensitive request data sits in your database. Also check which request parameters and headers your Telescope version records, and hide anything that carries tokens or passwords.
Steps
- Decide whether Telescope belongs in production. Many teams run it only in local and staging.
- If it stays, tighten the
viewTelescopegate and the Horizon authorization. - Add network limits in front of the paths.
- Schedule pruning.
- Review recorded fields for secrets.
- Include both packages in your dependency scans and keep them updated.
The last step matters because a vulnerability in an admin dashboard package is a direct route to the data it shows.
Quick check
Is Telescope open to everyone by default?
No. The docs say that by default it is available only in the local environment, and you define the gate for other environments.
Does Horizon need its own gate?
Yes. Horizon has its own dashboard authorization section in its documentation. Configure it explicitly.
Safeguard's dependency scanning can show when packages like these have known advisories, and reachability analysis helps you rank them. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
