Choose Error Events, Logs, or Breadcrumbs

Unofficial preview — not affiliated with Sentry. This prototype does not modify or replace Sentry documentation.

Automatic exception capture#

Use ignore_exceptions for exception classes that represent expected application behavior. The bundle performs an is_a check, so ignoring a parent class also affects its subclasses.

# config/packages/sentry.yaml
sentry:
  options:
    ignore_exceptions:
      - Symfony\Component\HttpKernel\Exception\NotFoundHttpException
      - Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException

Only add an exception after confirming that it is expected in your application. This setting suppresses matching error events; it does not filter unrelated Structured Logs.

Structured Logs#

Structured Logs send accepted Monolog records to the Sentry Logs interface. Context values become searchable attributes.

Use Structured Logs when you need to search operational messages such as job state, integration outcomes, or business-process failures. Do not add the handler to every channel until you have measured the resulting volume.

# config/packages/monolog.yaml
monolog:
  handlers:
    sentry_logs:
      type: service
      id: Sentry\SentryBundle\Monolog\LogsHandler
# config/packages/sentry.yaml
services:
  Sentry\SentryBundle\Monolog\LogsHandler:
    arguments:
      - !php/const Monolog\Logger::WARNING
 
sentry:
  options:
    enable_logs: true

Sentry documents automatic flushing when a request or command finishes. log_flush_threshold can send partial batches, but each flush makes a network request and can add latency.

Breadcrumbs provide context for a later error event and do not send a standalone log directly. Use them for recent application actions that help explain an exception but do not need to be queried as an independent log dataset.

Decision rule#

  • Choose error events when the unit of investigation is a failure.
  • Choose Structured Logs when the unit of investigation is a searchable message.
  • Choose breadcrumbs when the message matters only as context for a later failure.

Next steps#

Apply the safe production configuration, then compare the result with the official Symfony Logs guide.

Updated

Was this page helpful?