Skip to main content
Logfire for PHP

PHP observability with OpenTelemetry

OpenTelemetry-native observability for any PHP app, from the team behind Pydantic. Autoloading wires it up and flushes on exit, so even a request-per-process app sends complete traces, all queryable with SQL. Free for 10 million spans, logs, and metrics a month.

Start free with PHP As Markdown
Getting started

Install and configure

pecl install opentelemetry
composer require open-telemetry/sdk open-telemetry/exporter-otlp php-http/guzzle7-adapter open-telemetry/opentelemetry-auto-slim
export OTEL_PHP_AUTOLOAD_ENABLED=true
export OTEL_SERVICE_NAME=hello-php
export OTEL_EXPORTER_OTLP_ENDPOINT=https://logfire-us.pydantic.dev
export OTEL_EXPORTER_OTLP_HEADERS='Authorization=your-write-token'
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
<?php
require __DIR__ . '/vendor/autoload.php';

\OpenTelemetry\API\Globals::tracerProvider()
    ->getTracer('hello-php')
    ->spanBuilder('Hello World')
    ->startSpan()
    ->end();

PHP auto-instrumentation hooks through the opentelemetry extension, so pecl install it and enable it in your php.ini; opentelemetry-auto-slim is what turns Slim routes into spans. Swap it for the package matching your framework — without one you still get your own spans, just not the framework's. The OTLP exporter also needs a PSR-18 HTTP client, which is what php-http/guzzle7-adapter provides. There is no Logfire PHP SDK to adopt: this is the standard OpenTelemetry SDK exporting over OTLP. Full details are in the PHP setup guide.

What you get

One request, one trace

A Logfire trace of a PHP request handled by Slim, showing the route, the closure and the service's own spans

What lands in Logfire:

  • the Slim route span, timed and carrying its status code
  • the {closure} that handles it, from the Slim auto-instrumentation
  • your own calculate-quote span, nested where it ran
  • each log line attached to the span that emitted it, not to the request
How it works

Standard OpenTelemetry, hosted backend

Autoloading does the wiring, and the flushing

With OTEL_PHP_AUTOLOAD_ENABLED set to true, the SDK builds a tracer provider from your environment when the app loads and flushes it when the script ends. That last part matters more in PHP than anywhere else: the request-per-process model means a missed flush is lost telemetry, and autoloading removes that failure mode instead of leaving it to you.

Standard OTLP, so genuinely no lock-in

Configuration is OTEL_ environment variables against the standard OpenTelemetry PHP SDK. Your composer.json contains OpenTelemetry packages and nothing of ours, so moving to a different backend is a config change rather than a migration.

Traces, metrics, and logs in one place

Logfire is not just tracing. Send metrics and structured logs alongside your traces, build dashboards, and set alerts, all in the same OpenTelemetry-native project, and query all of it with the same SQL.

SQL instead of a query language you have to learn

Query your traces, metrics, and logs with PostgreSQL-compatible SQL. Any question you can express in SQL becomes a dashboard, an alert, or an ad-hoc investigation, and AI assistants are already fluent in it.

Query

Query your telemetry with SQL

select
  attributes->>'http.route' as route,
  count(*) as requests,
  avg(duration) as avg_seconds
from records
where duration > 1
group by route
order by avg_seconds desc;

Your traces, metrics, and logs are queryable with real SQL, no proprietary query language to learn. Any question you can express becomes a dashboard, an alert, or a one-off investigation.

Proof

In production

“You can tell that Pydantic Logfire was built by people who use it.”
Dennis Griffin, VP of Engineering, Sophos Read the case study
Decision guide

Is Logfire right for you?

Choose Logfire if

  • You want request traces from a PHP app without a proprietary agent
  • You want only OpenTelemetry packages in your composer.json
  • You want to query traces, metrics, and logs with PostgreSQL-compatible SQL
  • You do not want to run Jaeger, Prometheus, and storage yourself
  • You want the option to repoint at another backend without a rewrite

Choose a vendor APM if

  • You want a vendor-maintained PHP SDK with vendor-specific APIs
  • You are already deeply integrated with a specific APM vendor's ecosystem
  • You need a vendor-only integration or compliance capability Logfire does not offer
FAQ

Common questions

Is there a Logfire SDK for PHP?

No. PHP uses the standard OpenTelemetry PHP SDK, and Logfire is the OTLP backend it exports to, so nothing proprietary enters your composer.json. First-party Logfire SDKs exist for Python, TypeScript, and Rust.

composer require fails with no PSR-18 HTTP client found

The OpenTelemetry OTLP exporter needs a PSR-18 HTTP client and does not bundle one. Install php-http/guzzle7-adapter, or any other PSR-18 implementation you prefer, alongside the SDK and exporter packages.

The script runs but nothing appears in Logfire

Autoloading is almost always the cause. With OTEL_PHP_AUTOLOAD_ENABLED set to true, the SDK builds a tracer provider from your environment variables when the app loads and flushes it when the script ends. Without it, no tracer provider is created and spans go nowhere.

Nothing arrives from a self-hosted instance with a private certificate

PHP's HTTP client does not trust a private CA and ignores the OpenTelemetry certificate environment variable. Set openssl.cafile to your CA bundle in php.ini, or pass php -d openssl.cafile=/path/to/ca.pem when running.

Am I locked in to Logfire?

No. Configuration is standard OTEL_ environment variables against the standard OpenTelemetry PHP SDK, and your code references OpenTelemetry APIs only. Repoint the endpoint at another OpenTelemetry-compatible backend, or at your own collector, whenever you want.

Start seeing your PHP app

Get started with 10 million free spans, logs, and metrics per month. No credit card required.

Start free View pricing plans