Data Forwarding: support log event types for external export

Data Forwarding currently supports only error events. Logs captured via the Sentry Logs product cannot be forwarded to external systems, leaving teams that centralize observability data in a data warehouse or downstream store without a push-based path for log data.

Current behavior

• Data Forwarding (Splunk, Amazon SQS, Segment) forwards processed error events only.
• Logs, spans, and other event types are explicitly unsupported.
• Teams can export logs manually via the Explore UI or pull them via API, but there is no push-based forwarding mechanism.

Gap

Teams that route observability signals into a data warehouse, database, or log aggregation system have no way to include Sentry logs in that pipeline without polling the API. This creates operational overhead and makes it harder to join log data with other signals (errors, traces, metrics) in downstream systems.

Options

• Extend the existing Data Forwarding pipeline to support log event types alongside errors, using the same destination connectors (SQS, Splunk, Segment).
• Introduce a generic webhook/streaming export for logs that is destination-agnostic, letting teams route to any data warehouse, database, or log store without requiring a first-party connector per destination.
• Support both: a generic export mechanism as the foundation, with opinionated connectors layered on top for common destinations.

Related

• getsentry/sentry#112653 — Data Forwarding: batching + field filtering (errors)
• getsentry/sentry#112171 — Custom log export formats (UI/API)
• getsentry/sentry#106176 — Data Forwarding: Databricks destination

Start by reviewing the existing Data Forwarding pipeline and its Splunk, Amazon SQS, and Segment connectors. Read the related issues on batching, field filtering, log export formats, and Databricks destination before choosing an approach. Done requires an agreed design and a defined way to forward Sentry log events to external systems.