Telescope Guzzle Watcher Laravel Package

Product Decisions This Supports

• Build vs. buy for outbound HTTP observability. Laravel Telescope's built-in HTTP Client Watcher only sees calls made through the Http facade. Any call made through raw guzzlehttp/guzzle, or through SDKs that wrap Guzzle (AWS, Stripe, Google, most PHP vendor SDKs), is invisible today. This package closes that gap with one watcher class and zero call-site changes — a strong "adopt, don't build" case versus spending 1–2 engineer-days writing and maintaining equivalent instrumentation.
• Integration reliability as a tracked product metric. Once Guzzle traffic is in Telescope, you can answer product-relevant questions with data: which third-party APIs are slowest, which integrations fail most, what our p95 outbound latency is, and whether a customer-facing bug is ours or a vendor's. That feeds vendor selection, contract/SLA conversations, retry and fallback design, and whether a flaky integration should block a launch.
• Incident response and MTTR. Request/response payloads, status codes, and timing in one place shorten the "is it us or them?" loop during an outage. For a PM, that is a direct lever on support escalation cost and on how confidently you can communicate status to customers.
• Architecture standardization decisions. If most outbound traffic bypasses Laravel's HTTP client, this package is a cheap stopgap while you decide whether to standardize on the facade (in which case the package becomes unnecessary) or accept raw Guzzle and keep the watcher. It makes that trade-off visible rather than assumed.
• APM investment timing. This is deliberately a pre-production/development tool. Running it gives you evidence of whether you need a real APM/tracing vendor — sample rates, retention needs, alerting gaps — before you sign a contract. It de-risks the larger buy decision.
• Scoping for a specific epic, not the roadmap. With ~99 stars, zero dependents, and a low opportunity score, this is a tactical enabler for a debugging or integrations epic. Do not plan a platform strategy on top of it.

When to Consider This Package

Adopt when most of these hold:

• You run Laravel with Telescope enabled in local/staging and already rely on it as your debugging surface.
• You have meaningful outbound traffic outside the Http facade — legacy Guzzle clients, vendor SDKs, or a service layer another team owns.
• The pain is concrete and recent: an integration bug you could not diagnose from existing logs.
• You need a fix this sprint; install-and-register is hours, not weeks.
• You can accept a small, single-maintainer dependency and mitigate it by pinning the version or vendoring/forking the watcher (it is a thin wrapper around Guzzle's on_stats option, so the fork cost is low).

Look elsewhere — or do not adopt — when:

• You need production-grade observability. Telescope writes to your database synchronously and is not built for production volume, sampling, retention, or alerting. Choose OpenTelemetry, Sentry, Datadog, or New Relic instead.
• You have no Telescope, or your team is not Laravel-centric.
• High outbound request volume in the instrumented environment would bloat Telescope's tables or slow requests; this can degrade the very latency you are trying to measure.
• Compliance or audit requirements demand immutable, retained, access-controlled logs. Telescope entries can contain credentials and PII — API keys in headers, tokens and customer data in bodies. You must configure redaction and pruning before enabling this anywhere sensitive.
• You need vendor support or an SLA, or your dependency policy requires active multi-maintainer projects. Zero dependents and a small star count mean limited ecosystem validation.
• You only use Laravel's Http facade — you already have this coverage for free.

How to Pitch It (Stakeholders)

For executives: A free, MIT-licensed add-on that makes our outbound API calls visible in the debugging tool we already use. It targets the most expensive part of integration incidents — the hours spent proving whether a failure is ours or a vendor's — and it costs roughly an afternoon of one engineer's time with no new vendor, contract, or infrastructure. It also produces the latency and error data we need to hold third-party providers accountable and to decide, with evidence, whether a paid monitoring platform is justified.

For engineering: Telescope's HTTP Client Watcher misses everything that doesn't go through the Http facade — which is most of our SDK traffic. This package registers a custom watcher that hooks Guzzle's on_stats request option and records request, response, and timing data into the existing Telescope HTTP Client Watcher, so there are no changes at call sites and no proxy in the request path. Integration is config-only. Two caveats to own up front: redact sensitive headers and bodies before enabling, and treat it as a non-production tool. Maintenance risk is real but bounded — pin the version, or fork the watcher, since it is a small, single-purpose class with no transitive surface. Recommend a time-boxed pilot in staging, a redaction config review, and a decision checkpoint on whether to standardize outbound calls on the Http facade instead.