- What does laravel-pulse-guzzle-recorder do?
- It adds a Pulse recorder and Guzzle middleware that capture outgoing requests made through raw Guzzle clients and write them into Laravel Pulse's Slow Outgoing Requests section. That makes third-party SDK traffic and slow dependencies visible in the Pulse dashboard alongside other outgoing requests.
- How do I install and configure it for Laravel Pulse?
- Install it with composer require muhammadhuzaifa/laravel-pulse-guzzle-recorder, publish the package config if the README instructs it, then register the recorder in config/pulse.php. You also need to attach the middleware to each Guzzle client handler stack; installation alone does not instrument clients that do not use it.
- Does it record every Guzzle request automatically?
- No. Guzzle middleware only observes clients whose HandlerStack includes it, so apps that centralize client creation in a factory, base SDK wrapper, or container binding get broad coverage from one change. If vendors or SDKs build their own clients internally, coverage is partial, which can make the dashboard look more complete than it is.
- Will Guzzle requests through Laravel's Http facade be double-counted?
- Pulse's built-in SlowOutgoingRequests recorder already tracks requests made through Laravel's Http facade, so adding Guzzle middleware to clients that wrap Http can double-count. Keep the two paths separate: either exclude Http-backed clients from this middleware or standardize on one instrumentation path.
- Which Laravel, PHP, Pulse, and Guzzle versions are supported?
- The authoritative Laravel, PHP, Pulse, and Guzzle version constraints are in the package composer.json and README. Because the package couples to Pulse's recorder contract and table schema, pin exact Pulse and Guzzle versions in your app and verify the CI matrix before upgrading.
- What request data does the recorder capture?
- The recorder captures the request URL, HTTP method, status code, duration, and errors so Pulse can show slow or failing Guzzle calls. It is intended for outgoing request monitoring rather than full payload logging; check the config and code before assuming request or response bodies and headers are stored.
- How do I test that Guzzle requests are being recorded?
- Trigger a Guzzle request through an instrumented client, then confirm the entry appears in Pulse's Slow Outgoing Requests card. For automated tests, assert that the recorder receives the expected URI, method, status, and duration, and keep Pulse enabled or fake the recorder as your test setup requires.
- How are async Guzzle requests and pools timed?
- Timing is measured as observed by the middleware, so synchronous calls are straightforward. Asynchronous requests and Guzzle pools can be misleading because completion time and time-to-first-byte are not the same thing; validate the numbers against your own benchmarks before treating pooled request durations as authoritative.
- Is it safe to record URLs that contain API tokens or secrets?
- URLs can contain API tokens or secrets in query strings, so redact sensitive values before they reach Pulse or avoid putting secrets in query parameters. Treat the pulse tables as production telemetry with retention limits, and control collection by removing the recorder from config/pulse.php or disabling Pulse outside production.
- Is this package actively maintained, and what are the alternatives?
- It is a small, single-maintainer package with low adoption, so plan for the possibility of abandonment rather than assuming long-term support. The code surface is small enough to fork cheaply, and alternatives include instrumenting Guzzle with OpenTelemetry or routing traffic through Laravel's Http facade so Pulse records it natively.