Currently log drains have entirely fixed output. That means we cannot transform logs in any way which makes it difficult to work with the logs in other services. Specifically in our case we drain logs to Sentry but have no way to associate those logs with user sessions in our app because we cannot set a trace id on the logs. The best we can currently do is add a header with a unique session id since that shows up in log metadata, but that's less than ideal since it requires manual querying on the sentry end in order to correlate anything.
I think log drains would be a lot more valuable if we could transform the logs before they're sent out and/or customize them in some way. This would provide the flexibility needed to work with formats external tools expect. Log drains are less useful when they make the assumption that everything else will consume logs in exactly the format Supabase sends, since almost none will, but that's the current state of things.
Andrew M requests the ability to customize log drains to better integrate with services like Sentry. The current fixed output format limits the ability to associate logs with user sessions due to the lack of trace ID customization. The discussion includes potential solutions like mapping fields or using external tools like Vector for log transformation. Other users agree on the need for this feature to improve integration with various log platforms.
Thanks for laying this out. The use case makes sense: log drains are most useful when they can preserve the context that downstream tools use for correlation, and a fixed payload makes that hard for systems like Sentry that expect trace/session fields in specific places.
The main feature request here seems to be configurable enrichment/mapping before delivery, not just “send logs somewhere”. For example:
For the Sentry case specifically, being able to promote a session or trace identifier into the drained log payload would be much better than relying on a header that only appears as metadata and then manually querying around it later.
Arbitrary transforms may be harder to support safely because log drains need to stay reliable, predictable, and low-latency, but a declarative mapping layer could cover a lot of practical cases without turning drains into a full processing pipeline.
This would also help beyond Sentry. Most log platforms have their own preferred shape for severity, timestamp, service name, trace id, environment, and metadata, so some amount of payload customization would make drains easier to integrate generally.
This sounds worth tracking as a feature request for log drain configuration: field mapping/enrichment first, with more advanced transforms considered separately if there’s enough demand.
If my answer solved your problem, you can click answered the question. I'm really here to help, and along the way I'm also collecting Galaxy Brain badges haha 😆
Agree this is a real gap — fixed-format drains are hard to slot into anything that expects its own shape, and the "add a session-id header and correlate manually in Sentry" trick is exactly the kind of workaround that shows the feature needs a transform step.
Until there's native customization, the pragmatic pattern is to drain to something you control and reshape there: point the log drain at your own HTTP endpoint (an edge function, a small worker, or a Vector/Fluent Bit instance), enrich/rename fields — inject your trace id, remap to Sentry's expected structure — and forward on. Vector in particular is well-suited to this (an http_server source → remap transform with VRL → sentry/http sink) and gets you the trace-id association you're after without waiting on the feature.
That's clearly more moving parts than a built-in transform, so it's a reasonable thing to want first-class. Worth keeping this as a Feature Request and getting others who drain to Sentry/Datadog/etc. to upvote — the "let me set a trace id / template the payload before it leaves" ask is broadly useful, not just your case.
I didn't know about Vector, thanks, seems like a good tool for the job and probably very cheap to run on a tiny fly.io instance or similar. I might give that a shot.