Betterstack Logs Laravel Package

Product Decisions This Supports

• Build vs. buy on log shipping. The default engineering instinct for a product team is to hand-roll a log shipper or keep grepping files on the box. This package removes that roadmap item entirely: it's a thin, config-only Laravel log channel, so "we need centralized logs" becomes a vendor-and-config decision rather than a multi-sprint engineering project.
• Observability vendor consolidation. Adoption is only meaningful if we standardize on Better Stack. This package is the concrete mechanism for that decision in the Laravel ecosystem — it's the lowest-friction way to make the vendor choice real rather than aspirational, and it keeps us off a bespoke integration we'd own forever.
• Diagnosis speed as a product metric. Every feature decision about logging is really a decision about MTTR and incident blast radius. Routing structured context (order ID, tenant ID, job class, request ID) into a searchable system directly shortens the time between "customer reports problem" and "we know which request caused it." That's a support-cost and reliability lever, not just an infrastructure nit.
• Roadmap candidates this unlocks. Correlation IDs across requests and jobs, queue/scheduler failure visibility, per-environment log routing (local files, hosted logs for staging/prod), and PII redaction helpers. These are small platform investments that this package makes cheap to justify.
• Observability spend control. Because the channel is level-configurable and composable into a Laravel stack, log volume is a dial we can turn per environment. That makes Better Stack ingestion cost a predictable line item we can govern, rather than a bill that scales with our most verbose debug statement.
• Explicit non-decision: it is not an audit trail. If a compliance or retention requirement lands on the roadmap, this package does not satisfy it. Treat hosted logs as diagnostic tooling and keep durable archival logging alongside it — deciding that boundary early prevents a costly re-architecture later.

When to Consider This Package

Adopt when: we're already on (or actively standardizing on) Better Stack; the stack is Laravel 8+/PHP 8-ish on Monolog; we want structured, searchable logs without application changes; the team is small enough that we don't want to own a logging integration; and we can live with a config-only, one-line-revertible change — which is exactly the blast radius you want from a logging decision.

Look elsewhere when:

• There's no Better Stack contract. The package is a wrapper around a vendor choice. Evaluate the vendor first — the package is only as good as that decision.
• We need guaranteed delivery or buffering semantics. Logging libraries conventionally swallow transport errors, so a bad token can look identical to "no traffic." If delivery reliability is a requirement, we need a solution with explicit queueing and confirmation.
• We need a supported, well-resourced dependency. Six stars and a single maintainer is a real support and bus-factor risk. Acceptable for a swappable config-layer dependency; not acceptable if it's on the critical path.
• We need metrics, traces, or OpenTelemetry. This is logs only. If the observability strategy is broader than log search, start with a full-platform approach (Laravel Nightwatch, OTel, or an APM vendor) rather than bolting on a log channel.
• We're handling regulated data at high volume. Redaction is our code-review responsibility, not something the package handles for us. If PII in logs is a live risk, budget for a redaction processor and sampling strategy, or reconsider sending logs off-infrastructure at all.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk integration that gets our application logs off individual servers and into a searchable system, which shortens incident diagnosis and reduces support cost. It's a configuration change, not an application rewrite — no schema changes, no data migration, and rollback is a one-line config revert. It only makes sense as confirmation of the Better Stack decision; treat them as one decision, not two. The honest caveats: it's a thin single-maintainer open-source package, so we hedge by keeping a local file sink in the same logging stack, and we keep log volume — and therefore cost — under deliberate control via per-environment levels.

To engineering: Drop-in Laravel log channel driver. Composer install, token in env, add a channel to config/logging.php, compose it into the existing stack channel so local files remain the fallback if ingestion fails. No middleware, no service container overrides, no footprint. The real work isn't integration, it's policy: which channels route to Better Stack, at what verbosity, and how we structure log context so it's actually queryable. Plan a half-day spike to measure whether the handler adds request latency, deliberately break a token in staging to confirm failures are visible to us, then roll out at warning and above before expanding. Add it to the dependency-review queue — it's designed to be replaceable, and we should be willing to replace it if maintenance stalls.