Monolog Bridge Laravel Package

Product Decisions This Supports

• Serverless migration go/no-go (Laravel → AWS Lambda): Log quality is a standard objection to moving off EC2/containers — "we lose our log viewer." This package is a concrete answer: structured error logs, filterable by level, exception class, and Lambda request ID, without standing up a new observability vendor.
• Build vs. buy vs. configure for observability: The realistic third option. Rather than buying a log platform or having an engineer write a custom Monolog formatter, this is a one-line config change (LOG_STDERR_FORMATTER). It removes a line item from the roadmap.
• Incident response / MTTR roadmap input: The request-ID prefix and nested exception records directly reduce time-to-triage on production errors. It supports prioritization of "debuggability" work that rarely gets its own ticket.
• Log cost and retention decisions: CloudWatch charges on ingestion and on Logs Insights queries. Compact, single-line records with no timestamp/channel noise mean less volume scanned per query — a small but defensible input to the cost model.
• Feature-level use cases: error dashboards, alerting on level = 'ERROR' filtered by exception.class, per-invocation trace reconstruction, and audit-friendly structured context on business events.
• Compliance/audit posture: Consistent, machine-parseable records are easier to retain, export, and query than multi-line text blobs.

When to Consider This Package

Consider it when all of the following hold:

• You are running Laravel (or Symfony, or plain PHP) on AWS Lambda via Bref.
• CloudWatch Logs is your primary log destination, and you intend to use Logs Insights.
• Your team has been bitten by multi-line stack traces, unfilterable log levels, or "which invocation was this?" — i.e., you have a real triage pain, not a hypothetical one.
• You want zero new vendor commitment and near-zero integration cost.

Important PM caveat: if you use Bref's Laravel or Symfony bridge, this is already installed. The decision is not "adopt a dependency," it is "set one environment variable." Frame it that way internally to avoid a needless procurement conversation.

Look elsewhere when:

• You ship logs to Datadog, New Relic, Honeycomb, Grafana/Loki, or an OpenTelemetry pipeline — those tools want their own formatter, and this one is CloudWatch-shaped.
• You are not on Lambda — the request-ID and stderr conventions earn nothing on ECS or a VM.
• You need distributed tracing or correlation across services — this is a formatter, not instrumentation. Pair it with OTel; do not present it as a substitute.
• You require a commercially supported or vendor-backed component. This is a tiny, single-maintainer, MIT-licensed utility. The code surface is small enough that the risk is "we fork it in an afternoon," not "we are stranded" — but be honest about that in the risk register.

How to Pitch It (Stakeholders)

One-liner for executives: "A free, already-bundled logging configuration that makes our Lambda error logs searchable in AWS, cutting the time an engineer spends reconstructing what broke in production."

What it does: Reformats each log line as a short human-readable message followed by a JSON payload. CloudWatch parses the JSON automatically, so logs stay readable in the console and become filterable — by severity, by exception class, by request ID — in Logs Insights.

Why now: If Lambda is on the roadmap, this removes a predictable blocker from the migration review. If Lambda is already live, this is a low-risk quality fix to a known operational annoyance.

Cost and effort: No licence fee, no new vendor, no procurement. One environment variable in serverless.yml. Roughly a half-day of engineering including verification, assuming a Laravel app already on Bref's bridge.

Risk, stated plainly: Eleven GitHub stars, zero dependents, one maintainer, MIT licence, small codebase. This is a utility, not a platform. Mitigation is trivial: the formatter is a single class, and we can vendor or fork it if upstream goes quiet. Do not let the low star count be used as an argument against a change this small; equally, do not let it be sold as a strategic observability investment.

What it is not: Not a replacement for tracing, APM, or a log aggregation platform. If we later buy Datadog, this gets retired. Recommend it as the correct default for the Lambda-on-CloudWatch path today, with the understanding that it is deliberately disposable.