---
title: "Logs"
description: "Structured logs allow you to send, view and query logs sent from your applications within Sentry."
url: https://docs.sentry.io/platforms/php/logs/
---

# Set Up Logs | Sentry for PHP

With Sentry Structured Logs, you can send text-based log information from your applications to Sentry. Once in Sentry, these logs can be viewed alongside relevant errors, searched by text-string, or searched using their individual attributes.

## [Requirements](https://docs.sentry.io/platforms/php/logs.md#requirements)

Logs for PHP are supported in Sentry PHP SDK version `4.12.0` and above.

## [Setup](https://docs.sentry.io/platforms/php/logs.md#setup)

To enable logging, you need to initialize the SDK with the `enable_logs` option set to `true`.

```php
\Sentry\init([
    'dsn' => '___PUBLIC_DSN___',
    // Enable logs to be sent to Sentry
    'enable_logs' => true,
]);

// Somewhere at the end of your execution, you should flush the logger to send pending logs to Sentry.
\Sentry\logger()->flush();
```

## [Using with Monolog](https://docs.sentry.io/platforms/php/logs.md#using-with-monolog)

If you're already using [Monolog](https://github.com/Seldaek/monolog), you can use the `\Sentry\Monolog\LogsHandler` to send logs directly through your existing logging setup:

```php
use Monolog\Level;
use Monolog\Logger;

\Sentry\init([
    'dsn' => '___PUBLIC_DSN___',
    'enable_logs' => true,
]);

$log = new Logger('app');
$log->pushHandler(new \Sentry\Monolog\LogsHandler(
    hub: \Sentry\SentrySdk::getCurrentHub(),
    level: Level::Info,
));

// Your existing Monolog usage will now send logs to Sentry
$log->info('Application started');

// Don't forget to flush
\Sentry\logger()->flush();
```

For more details, see the [Monolog integration documentation](https://docs.sentry.io/platforms/php/integrations/monolog.md#logs).

## [Usage](https://docs.sentry.io/platforms/php/logs.md#usage)

Once the feature is enabled on the SDK and the SDK is initialized, you can send logs using the `logger()` function.

The `logger()` function exposes six methods that you can use to log messages at different log levels: `trace`, `debug`, `info`, `warn`, `error`, and `fatal`.

You can pass additional attributes directly to the logging functions. These properties will be sent to Sentry, and can be searched from within the Logs UI, and even added to the Logs views as a dedicated column.

```php
\Sentry\logger()->info('A simple log message');
\Sentry\logger()->info('A message with a parameter that says %s', values: ['hello']);
\Sentry\logger()->warn('This is a warning log with attributes.', attributes: [
  'attribute1' => 'string',
  'attribute2' => 1,
  'attribute3' => 1.0,
  'attribute4' => true,
]);

// Somewhere at the end of your execution, you should flush the logger to send pending logs to Sentry.
\Sentry\logger()->flush();
```

If you are using logs in long running CLI tasks, we recommend periodically calling `\Sentry\logger()->flush()` to keep memory pressure low and avoid any logs being discarded to due size-limits.

## [Automatic Log Flushing](https://docs.sentry.io/platforms/php/logs.md#automatic-log-flushing)

Logs are usually flushed at the end of a request or job. If a single request or job can produce a lot of log lines, set `log_flush_threshold` to flush automatically once the buffer reaches the configured size.

```php
\Sentry\init([
    'dsn' => '___PUBLIC_DSN___',
    'enable_logs' => true,
    'log_flush_threshold' => 5,
]);
```

We don't recommend flushing too often, because each flush sends a network request and can add latency. If you expect frequent flushes for a request or job, a local [Relay](https://docs.sentry.io/product/relay/getting-started.md) can help reduce that added latency.

## [Options](https://docs.sentry.io/platforms/php/logs.md#options)

#### [before\_send\_log](https://docs.sentry.io/platforms/php/logs.md#before_send_log)

To filter logs, or update them before they are sent to Sentry, you can use the `before_send_log` option.

```php
\Sentry\init([
    'dsn' => '___PUBLIC_DSN___',
    // Enable logs to be sent to Sentry
    'enable_logs' => true,
    'before_send_log' => function (\Sentry\Logs\Log $log): ?\Sentry\Logs\Log {
        if ($log->getLevel() === \Sentry\Logs\LogLevel::info()) {
            // Filter out all info logs
            return null;
        }

        return $log;
    },
]);
```

The `before_send_log` function receives a log object, and should return the log object if you want it to be sent to Sentry, or `null` if you want to discard it.

## [Best Practices](https://docs.sentry.io/platforms/php/logs.md#best-practices)

### [Wide Events Over Scattered Logs](https://docs.sentry.io/platforms/php/logs.md#wide-events-over-scattered-logs)

Instead of many thin logs that are hard to correlate, emit one comprehensive log per operation with all relevant context.

This makes debugging dramatically faster — one query returns everything about a specific order, user, or request.

```php
// ❌ Scattered thin logs
\Sentry\logger()->info('Starting checkout');
\Sentry\logger()->info('Validating cart');
\Sentry\logger()->info('Processing payment');
\Sentry\logger()->info('Checkout complete');

// ✅ One wide event with full context
\Sentry\logger()->info('Checkout completed', attributes: [
    'order_id' => $order->id,
    'user_id' => $user->id,
    'user_tier' => $user->subscription,
    'cart_value' => $cart->total,
    'item_count' => count($cart->items),
    'payment_method' => 'stripe',
    'duration_ms' => (microtime(true) - $startTime) * 1000,
]);
```

### [Include Business Context](https://docs.sentry.io/platforms/php/logs.md#include-business-context)

Add attributes that help you prioritize and debug:

* **User context** — tier, account age, lifetime value
* **Transaction data** — order value, item count
* **Feature state** — active feature flags
* **Request metadata** — endpoint, method, duration

This lets you filter logs by high-value customers or specific features.

```php
\Sentry\logger()->info('API request completed', attributes: [
    // User context
    'user_id' => $user->id,
    'user_tier' => $user->plan, // "free" | "pro" | "enterprise"
    'account_age_days' => $user->ageDays,

    // Request data
    'endpoint' => '/api/orders',
    'method' => 'POST',
    'duration_ms' => 234,

    // Business context
    'order_value' => 149.99,
    'feature_flags' => ['new-checkout', 'discount-v2'],
]);
```

### [Consistent Attribute Naming](https://docs.sentry.io/platforms/php/logs.md#consistent-attribute-naming)

Pick a naming convention and stick with it across your codebase. Inconsistent names make queries impossible.

**Recommended:** Use `snake_case` for custom attributes to match PHP conventions.

```php
// ❌ Inconsistent naming
['user' => '123']
['userId' => '123']
['user_id' => '123']
['UserID' => '123']

// ✅ Consistent snake_case
[
    'user_id' => '123',
    'order_id' => '456',
    'cart_value' => 99.99,
    'item_count' => 3,
]
```

## [Default Attributes](https://docs.sentry.io/platforms/php/logs.md#default-attributes)

The PHP SDK automatically sets several default attributes on all log entries to provide context and improve debugging:

### [Core Attributes](https://docs.sentry.io/platforms/php/logs.md#core-attributes)

* `environment`: The environment set in the SDK if defined. This is sent from the SDK as `sentry.environment`.
* `release`: The release set in the SDK if defined. This is sent from the SDK as `sentry.release`.
* `sdk.name`: The name of the SDK that sent the log. This is sent from the SDK as `sentry.sdk.name`.
* `sdk.version`: The version of the SDK that sent the log. This is sent from the SDK as `sentry.sdk.version`.

### [Message Template Attributes](https://docs.sentry.io/platforms/php/logs.md#message-template-attributes)

If the log was parameterized, Sentry adds the message template and parameters as log attributes.

* `message.template`: The parameterized template string. This is sent from the SDK as `sentry.message.template`.
* `message.parameter.X`: The parameters to fill the template string. X can either be the number that represent the parameter's position in the template string (`sentry.message.parameter.0`, `sentry.message.parameter.1`, etc) or the parameter's name (`sentry.message.parameter.item_id`, `sentry.message.parameter.user_id`, etc). This is sent from the SDK as `sentry.message.parameter.X`.

### [Server Attributes](https://docs.sentry.io/platforms/php/logs.md#server-attributes)

* `server.address`: The address of the server that sent the log. Equivalent to `server_name` that gets attached to Sentry errors.

### [User Attributes](https://docs.sentry.io/platforms/php/logs.md#user-attributes)

If user information is available in the current scope, the following attributes are added to the log:

* `user.id`: The user ID.
* `user.name`: The username.
* `user.email`: The email address.

### [Integration Attributes](https://docs.sentry.io/platforms/php/logs.md#integration-attributes)

If a log is generated by an SDK integration, the SDK will set additional attributes to help you identify the source of the log.

* `origin`: The origin of the log. This is sent from the SDK as `sentry.origin`.

## [Other Logging Integrations](https://docs.sentry.io/platforms/php/logs.md#other-logging-integrations)

Available integrations:

* [Monolog](https://docs.sentry.io/platforms/php/integrations/monolog.md#logs)

If there's an integration you would like to see, open a [new issue on GitHub](https://github.com/getsentry/sentry-php/issues/new/choose).