Laravel Blanket Laravel Package

Getting Started

Install (dev/local first). The dashboard writes a row for every outgoing HTTP client call, so treat it like Telescope — install it where you want observability, not necessarily everywhere.

composer require ahmadwaleed/laravel-blanket --dev
php artisan vendor:publish --provider="Ahmadwaleed\Blanket\BlanketServiceProvider"
php artisan migrate

Then visit /blanket (check config/blanket.php for the actual path key). If you get a 404, run php artisan route:clear — a cached route table from before install is the usual culprit.

Look at these files first, in order:

1. config/blanket.php — enable flag, route path, and middleware stack. This is the only file you should normally edit.
2. The package's service provider — confirms which Laravel HTTP client events (typically RequestSent, ResponseReceived, ConnectionFailed) it subscribes to, which tells you exactly what will and won't be captured.
3. The published migration — shows columns available for querying (method, URL, status, duration, headers, bodies).
4. routes/web.php in the package — how the dashboard is mounted and what middleware guards it.

First use case. You have a flaky third-party API call inside a queued job and the exception message is useless. Open /blanket, sort by most recent, click the failing entry, and read the exact request headers, JSON body, response status, and response body. This is the single biggest win over Log::info() sprinkled around Http:: calls.

Version caveat before you commit. Last release was September 2021, so it targets roughly Laravel 8/9. On Laravel 10/11 the underlying Illuminate\Http\Client\Events still exist and the package will often keep working, but test the dashboard route, asset loading, and the migration on your actual framework version before rolling it out to a team. If it breaks, it breaks at install time, which is cheap.

Implementation Patterns

Gate it behind the enable flag and real auth. Set BLANKET_ENABLED=true in .env for local and staging only, and set the config middleware to include auth (plus a gate/ability if the dashboard is reachable in a shared staging environment). The default is usually just web, which means anyone who guesses the path sees your API tokens.

// config/blanket.php
'enabled' => env('BLANKET_ENABLED', false),
'middleware' => ['web', 'auth', 'can:viewBlanket'],

Define viewBlanket in a service provider and grant it to your admin/dev role.

Use it as targeted Telescope, not a Telescope replacement. Blanket only sees traffic through Illuminate\Support\Facades\Http. That's deliberate: it's low-noise. If you're debugging a payments or CRM integration, this dashboard is more useful than Telescope's firehose because the list only contains outbound API calls.

Correlate with jobs and users. Requests fired inside queue workers still record — the service provider listens at the framework event level, so worker context doesn't matter. To make entries findable, include a correlation identifier in the outbound request yourself (a header like X-Request-Id, or the job's UUID in a query param). Then the dashboard's search becomes a debugging tool rather than a scroll-fest.

Prune aggressively. There is no built-in retention. Add a scheduled cleanup against the package's model/table:

// App\Console\Kernel or routes/console.php
Schedule::call(fn () => DB::table('blanket_requests')
    ->where('created_at', '<', now()->subDays(7))->delete())->daily();

Swap the table name for whatever the published migration created in your version.

Kill it in tests. Outbound calls in a test suite either hit Http::fake() (usually not recorded) or a real sandbox (recorded, polluting the table). Disable via config in phpunit.xml:

<env name="BLANKET_ENABLED" value="false"/>

Read it as a queryable table too. The UI is convenient, but the migration gives you a normal table. Ad-hoc SQL is often faster for aggregate questions: "which endpoint fails most?", "what's the p95 duration for the shipping API this week?" That's the pattern that turns Blanket from a curiosity into something you check weekly.

Gotchas and Tips

It stores secrets in plaintext. Authorization: Bearer …, API keys in query strings, session-bearing headers, and full response bodies all land in the database unencrypted. On staging or any shared DB, that's a real leak vector. If your version's config supports an ignore/redact list, use it; otherwise keep Blanket strictly local or scrub before sharing a DB dump.

Large payloads are the number one failure mode. An upload endpoint or a multi-megabyte JSON response can blow past column limits or bloat the table fast. Check the migration's column types (text vs longtext) and consider filtering noisy URLs out.

Not everything is captured, by design.

• Raw Guzzle/Curl calls, file_get_contents, and DB queries are invisible.
• Retries (->retry()) generate multiple request records — one per attempt — so a "single" flaky call looks like three rows.
• multipart and streamed bodies may be recorded incompletely or empty; don't trust the body column for file uploads.
• Binary/gzipped responses can look like garbage.

If you're missing an entry, confirm the call actually goes through Http:: before assuming a package bug.

Config caching bites on setup. php artisan config:cache right after publishing will leave you with stale or missing keys; clear config and route caches when changing enabled, path, or middleware.

Synchronous writes add overhead. Each recorded call incurs a DB insert on the request path. For a job that fires hundreds of HTTP calls, measure before enabling in a load test — or keep the flag off in that environment entirely.

The dashboard is not a production monitoring tool. No alerting, no sampling, no retention. If you need those, this package is a debugging aid, not an APM. Use it to answer "what did we actually send?" and use real metrics for "is it healthy?"

Extension point if you outgrow it. Because capture is event-driven, you can attach your own listeners to the same Illuminate\Http\Client\Events\* classes to push metrics to Prometheus or your logger, and keep Blanket purely as the human-facing inspector. That split is the sane long-term arrangement if the package stalls on newer Laravel versions — your instrumentation survives, only the UI goes away.