Feature Request: Apply transformations to $exception events and enforce error tracking toggle server-side

Feature request

Is your feature request related to a problem?

When error tracking is enabled, $exception events are routed at the capture layer to a dedicated Kafka topic (exceptions_ingestion) and processed by Cymbal — completely bypassing the analytics ingestion pipeline. This means transformations never run on exception events, so customers cannot use transformations to anonymize or redact sensitive data from error tracking.

Additionally, the "autocapture exceptions" toggle only controls whether the SDK automatically captures exceptions. If an application explicitly calls captureException() or has an error tracking integration, $exception events continue to be sent and ingested even when error tracking is "off". There is no server-side mechanism to drop these events.

This is a blocker for customers with anonymization requirements who want to use error tracking but need to strip PII from exception events before they're stored.

Describe the solution you'd like

1. Apply transformations to $exception events — either by running transformations within the error tracking pipeline (Cymbal), or by routing exception events through the analytics pipeline's transformation step before forwarding them to Cymbal.

OR

2. Server-side enforcement of the error tracking toggle — when a team has error tracking disabled, the capture layer (Rust) should drop $exception events entirely, rather than relying solely on the SDK to stop sending them.

Describe alternatives you've considered

• SDK-side before_send hooks: Customers can use before_send (posthog-js) or beforeSend (posthog-flutter 5.13.0+) to drop or redact $exception events client-side before they're sent. This works as a workaround but requires changes to every SDK integration, is not enforceable server-side, and doesn't help with backend SDKs that may lack this hook.

• Disabling exception capture entirely in application code: Removing all captureException() calls and error integrations stops the events, but means the customer loses error tracking entirely rather than being able to use it with anonymized data.

Additional context

From: https://posthoghelp.zendesk.com/agent/tickets/50567 (moved to PostHog: https://us.posthog.com/project/2/support/tickets/52580)

Debug info

Kind: support

Target area: data_management

Report event: http://go/ticketByUUID/5e063a59-81c3-413e-80b5-750ed3dcfa00

Session: https://us.posthog.com/project/sTMFPsFhdP1Ssg/replay/019c521b-20bc-7751-acc6-72076776572c?t=579

Exceptions: https://us.posthog.com/project/2/error_tracking?filterGroup=%7B%22type%22%3A%22AND%22%2C%22values%22%3A%5B%7B%22type%22%3A%22AND%22%2C%22values%22%3A%5B%7B%22key%22%3A%22%24session_id%22%2C%22value%22%3A%5B%22019c521b-20bc-7751-acc6-72076776572c%22%5D%2C%22operator%22%3A%22exact%22%2C%22type%22%3A%22event%22%7D%5D%7D%5D%7D

Location: https://eu.posthog.com/project/30216/data-management/events/019a15ec-95d2-7c50-96ec-cdd720ebfbc2

Persons-on-events mode for project: person_id_override_properties_on_events

Start by tracing the Rust capture layer, the exceptions_ingestion Kafka topic, Cymbal, and the analytics ingestion pipeline to determine where transformations and the error-tracking toggle can be enforced. Done means an agreed pipeline applies transformations to $exception events or drops them server-side when error tracking is disabled, with coverage for both paths.