# Requizon vs Laravel Telescope

> Telescope shows you one outgoing request in full while you build. Requizon shows you all of them, over weeks, in production.

Source: https://requizon.boring-observability.dev/vs/telescope
Section: Comparisons — Requizon
Updated: 2026-09-16

---

**Bottom line:** For local development Telescope is the better tool, and it costs nothing: every call with its headers, payload and response body, next to the queries and jobs around it. It is built to inspect individual entries, though. It keeps a day of data by default, draws no charts, and its default production filter does not keep outgoing requests at all. Requizon is built for the view Telescope does not have, which is how an API has behaved across the last fortnight.

[Laravel Telescope](https://laravel.com/docs/telescope) is where many Laravel developers first look at an outgoing request. Its HTTP client watcher shows each call with its headers, payload and response, next to the queries and jobs of the same request, and for debugging an integration on your laptop it is hard to beat. Requizon is not trying to beat it there. The two are built for different jobs, and the difference shows up once you ask either of them about last week in production.

## What the HTTP client watcher stores

Telescope listens for the events Laravel's HTTP client fires. For each response it stores one entry holding the method, URL, request headers, payload, response status, response headers, duration and the response body, when that body is JSON or plain text under the size limit (64 KB by default). A call that failed to connect is stored with the request side only. Each entry is tagged with the host, so you can filter the list down to one API.

You can hide values by name with `Telescope::hideRequestHeaders()`, `hideRequestParameters()` and `hideResponseParameters()`. Other values are stored as they were sent.

## In production, by default, it keeps none of them

The `TelescopeServiceProvider` that `telescope:install` publishes contains a filter. In the local environment it records everything. Everywhere else it keeps a short list of entry types, such as reportable exceptions, failed jobs and scheduled tasks, plus anything carrying a monitored tag. Outgoing HTTP client requests are not on the list, so a production install with the default filter records none of them. Laravel's documentation introduces Telescope as a companion to your local development environment, and the default follows from that.

You can widen the filter. Then every call becomes a row in `telescope_entries` with its headers and bodies, the table grows with your traffic, and `telescope:prune` (24 hours by default) is what keeps it in check. Even then Telescope shows a list of entries. It has no view of volume, response time or error rate over time, so "is this API worse than it was on Monday" becomes a query you write against the stored JSON.

## At a glance

| For outgoing requests | Telescope | Requizon |
| --- | --- | --- |
| Price | Free, MIT | A [one-time purchase](https://requizon.boring-observability.dev#pricing) per app |
| Built for | Inspecting individual entries | Trends per API over weeks |
| Records in production by default | No | Yes |
| Request and response headers | Stored | Never stored |
| Response body | Every JSON or text response under the size limit | Failed calls only |
| Redaction | The names you list | [Credential-shaped names by default](https://requizon.boring-observability.dev/docs/redaction), plus yours |
| Charts and aggregates | None | Response time and responses per API, host and path |
| Failure types | Status code per entry | [Connection, HTTP and application errors](https://requizon.boring-observability.dev/docs/failure-detection) |
| Raw Guzzle clients | Through a community watcher | [Bundled middleware](https://requizon.boring-observability.dev/docs/what-gets-recorded) |
| Default retention | 24 hours, if you schedule pruning | 14 days of calls and a year of hourly statistics, pruned on its own schedule |
| Other watchers | Queries, jobs, mail, cache, events, logs and more | None |
| Laravel versions | 8 to 13 | 12 and 13 |

## What Telescope does better

- **Seeing exactly what was sent.** Headers, the full payload and the successful response are all there. When an integration misbehaves because of a missing header, Telescope shows it and Requizon, which never stores headers, does not.
- **Context.** The call sits in the same batch as the request, queries and jobs that surrounded it. Requizon records the call on its own.
- **Everything else in the app.** Telescope has watchers for queries, jobs, mail, notifications, cache, events, logs, gates and more. Requizon watches one thing.
- **It is free** and maintained by the Laravel team.
- **Wider support.** Any Laravel from 8 onwards, and not tied to MySQL. Requizon needs Laravel 12 and MySQL 8.0.20+ or a compatible MariaDB.

## What Requizon is for

Requizon is meant to stay on in production. It stores no headers and redacts request parameters whose names look like credentials, keeps the response body only when a call failed, and [schedules its own pruning](https://requizon.boring-observability.dev/docs/retention). A scheduled command folds calls into hourly buckets by API, host and path, and the dashboard reads those, so a fortnight's chart does not get slower as your traffic grows.

What you get from that is the view Telescope does not have: each dependency's response time and outcomes over time, with `connection_error`, `http_error` and `application_error` stacked separately, and the individual failing calls a click away.

## Using the two together

They coexist without configuration. One setup that works well is Telescope in local development for the detail of the call you are working on, and Requizon in every environment for the history. If you run tests with both installed, set `REQUIZON_ENABLED=false` in `phpunit.xml`, since `Http::fake()` responses pass through Requizon's middleware and would otherwise be written to its tables.


## Common questions

### Does Laravel Telescope record outgoing HTTP requests in production?

Not with its default configuration. The filter telescope:install publishes records every entry in the local environment, and everywhere else only a short list of entry types, such as reportable exceptions, failed jobs and scheduled tasks, plus entries with a monitored tag. Outgoing HTTP client requests are not on that list. You can widen the filter, at which point every call becomes a row in telescope_entries.

### What does Telescope's HTTP client watcher store?

For each call through Laravel's HTTP client: the method, URL, request headers, payload, response status, response headers, the response body when it is JSON or plain text under the size limit (64 KB by default), and the duration. A connection failure is stored with the request side only. Entries are tagged with the host. Requizon stores no headers, redacts request parameters by name, and keeps a response body only when the call failed.

### Does Telescope show charts or error rates for outgoing requests?

No. Telescope lists entries and lets you open, search and filter them by tag. There is no aggregate view of volume, response time or failure rate over time, which is what Requizon's dashboard is made of.

### Can I use Telescope and Requizon together?

Yes, and in development that is a sensible setup: Telescope for the full detail of the call you are debugging, Requizon for the history. Turn Requizon off in your test suite with REQUIZON_ENABLED=false, since Http::fake() responses go through its middleware too.

### How long does Telescope keep entries?

telescope:prune deletes entries older than 24 hours by default, and takes an --hours option. Telescope's documentation tells you to schedule it daily because the table grows quickly without it. Requizon schedules its own pruning and keeps calls for 14 days and hourly aggregates for a year by default.