Laravel Graylog Laravel Package

Product Decisions This Supports

• Framework lifecycle planning: v1.15.0 confirms the package is actively maintained against modern Laravel (11/12) and PHP 8.4, which de-risks keeping it in the dependency graph as we upgrade the platform.
• Observability standardization: Deciding whether Graylog (or a Graylog-compatible GELF endpoint) is the log aggregation target for our services, and whether to lean on this package versus a generic Monolog/GELF handler.
• Build vs. buy vs. adopt: Reinforces that centralised logging transport is a solved problem we should not build in-house; the package is a thin, community-maintained glue layer.
• Upgrade roadmap inputs: The Laravel 10 → 11/12 migration path now has a confirmed compatible logging dependency, so logging is no longer a blocker in that roadmap item.
• Environment/use-case fit: Suitable for teams already running Graylog who want Laravel-native configuration (channels, formatters) rather than bespoke Monolog wiring per service.

When to Consider This Package

Consider adoption when:

• We run (or plan to run) Graylog, or any endpoint accepting GELF, as our log aggregation backend.
• The codebase is on Laravel 11 or 12 and PHP 8.2–8.4 (Laravel 10 is now explicitly dropped in v1.15.0 — pin to v1.14.x if still on Laravel 10).
• We want configuration-driven setup (a logging channel in config/logging.php) rather than custom Monolog handler code in each service.
• We value a maintained, small-surface integration over a heavier APM/observability suite.

Look elsewhere when:

• We are still on Laravel 10 or older, or on PHP versions below the supported matrix — v1.15.0 is a breaking bump for those environments.
• Our observability strategy is SaaS-first (Datadog, New Relic, Sentry, Grafana Cloud) and Graylog is not in the picture.
• We need advanced features (sampling, structured tracing, PII scrubbing beyond basic config) that belong in a broader logging/observability layer rather than a transport package.
• The team is uncomfortable depending on a single-maintainer community package for a critical path — in which case a generic Monolog GELF handler is a lower-coupling alternative.

How to Pitch It (Stakeholders)

For executives: A low-cost, low-risk dependency that lets our Laravel services ship logs to Graylog without custom engineering. The v1.15.0 release keeps it current with Laravel 12 and PHP 8.4, so it won't hold back our platform upgrades. No commercial licence, no vendor lock-in.

For engineering: Version 1.15.0 aligns the package with the current framework support window — Laravel 12 added, Laravel 10 removed, PHP 8.4 added to CI. Treat this as a breaking change in the support matrix: any service still on Laravel 10 must stay pinned to v1.14.x until it upgrades. It's a configuration-only integration (log channel + formatter), so adoption cost is minimal and the blast radius is contained to logging. Recommend adding a compatibility note to our upgrade runbook and gating the bump on the Laravel 10 → 11/12 migration completing.