# Attributes


The `attributes` object is a flat key-value map that contains all context data for the error. [Resource](/docs/protocol/general/resources) and [scope](/docs/protocol/general/resources#scope) attributes are merged into this single object.

This page covers what a PHP client puts there. For the page context, React errors and source map linking a browser client sends, see [Attributes](/docs/protocol-javascript/errors/attributes) in the JavaScript protocol docs.

Include as much context as possible: service info, host and OS details, git state, runtime info, request data, routing details, user info, etc. The more attributes you provide, the more useful Flare's filtering, grouping, and debugging tools become.

For the full list of recognized attribute keys, see [Resources](/docs/protocol/general/resources#attributes).

Some event types are inlined as attributes on the error rather than added to the `events` array. For example, [`php_request`](/docs/protocol/general/events#php_request) and [`php_routing`](/docs/protocol/general/events#php_routing) attributes are placed directly in the root `attributes` object. See the individual event type documentation for details.

## Entry Point

Every error report should describe the request, command, or job that the error happened in. The `flare.entry_point.*` attributes carry that information at the root of the `attributes` object. The same attributes are used by traces and logs, so they are documented in their own page: see [Entry points](/docs/protocol/general/entry-points) for the full schema, the handler-type catalog, and per-scenario examples.

## Exception Context

The `context.exception` attribute can contain additional context provided by the exception itself. This is an object with arbitrary key-value pairs that the exception class defines, useful for attaching structured debugging data to specific error types.

## Livewire

When the error occurs during a Livewire request, include the `livewire.components` attribute with the component data for the request. Each entry represents a Livewire component involved in the request.

| Attribute | Type | Description |
|---|---|---|
| `livewire.components` | array | Array of component objects |

Each component object:

| Field | Type | Description |
|---|---|---|
| `component_class` | string/null | Fully qualified component class name |
| `component_id` | string | Unique component instance ID |
| `component_alias` | string/null | Component alias |
| `data` | object | Component public properties/state |
| `memo` | object/null | Component metadata (id, name, path, method, children, errors, locale) |
| `updates` | array | Data updates sent in the request, each with `type` and `payload` |
| `calls` | array/null | Method calls on the component, each with `path`, `method`, and `params` |

## Database Errors

When the error is a database exception (e.g. `QueryException`, `PDOException`), include the `flare.exception.db_statement` attribute with the SQL query that caused the error. Flare uses this to group SQL errors by their query instead of by the raw exception message. Optionally add `flare.exception.db_system` (e.g. `mysql`, `pgsql`) to describe the database; it defaults to `mysql` when omitted.

These root-level `flare.exception.*` attributes are distinct from the span-level `db.statement` attribute used inside [`php_query`](/docs/protocol/general/events#php_query) events.

## Jobs & Commands

When an error occurs during a job or command, include a `laravel_job` or `php_command` event in the `events` array with the appropriate failure attribute (`laravel.job.success` set to `false` for jobs, or `process.exit_code` for commands). This allows Flare to track failure rates alongside the error.