Choosing an ingestion path
A decision guide for getting data into Sazabi — connect a supported account, run your own collectors, or instrument application code.
Sazabi supports two setup paths — connect your account, or send to an endpoint — and the send-to-an-endpoint path covers several methods. This page helps you pick. For most projects, start by checking whether your platform is in the connect-your-account list; it is the least setup.
Is your platform a supported cloud platform?
Recommended when: your logs live on a platform Sazabi can connect to directly (for example Vercel, Cloudflare, Sentry, Google Cloud, or AWS CloudWatch).
Use the connect-your-account path. You authorize Sazabi once and it pulls your logs — no collector to run and no key to embed in your infrastructure. Browse the Connect your account list to see if your platform is there.
Use an alternative when: your platform is not in the list, or you want explicit control over exactly which records leave your environment.
Trade-offs: least setup and no infrastructure to maintain, but you get the data the platform exposes to Sazabi rather than a stream you shape yourself.
Do not use when: your platform is not in the connect-your-account list.
Do you run your own collectors?
Recommended when: you already run an OpenTelemetry Collector, Grafana Alloy, Fluent Bit, Vector, or a Datadog Agent.
Send to an endpoint from your collector. Add your project's intake URL as a destination. This keeps your existing pipeline and adds Sazabi as one more sink. See the collector entries under Send to an endpoint.
Use an alternative when: you do not run a collector and do not want to.
Trade-offs: full control over what you forward and how it is shaped, at the cost of running and maintaining the collector.
Do not use when: connecting your account covers your platform with less work.
Are you instrumenting backend code?
Recommended when: you want telemetry from inside your backend — logs and traces emitted by the application itself.
Instrument with the OpenTelemetry SDK. Point it at your log source's intake URL and it sends logs and traces as your code runs. See OpenTelemetry.
Use an alternative when: the data you need is already available by connecting your platform account, or a collector you run already ships it.
Trade-offs: the richest, most application-specific data, at the cost of code changes.
Do not use when: a platform connection already gives you the signals you need.
Are you instrumenting a frontend app?
Recommended when: you want browser-side telemetry — errors, console output, network activity, and interaction events from your users' browsers.
Use the Sazabi browser SDK. It captures a semantic event stream and injects trace context so browser events correlate with your backend logs. See Instrument your frontend.
Use an alternative when: you already run Sentry or PostHog in the browser — repoint that SDK at your intake URL instead of adding a second one. The frontend guide compares the options.
Trade-offs: first-party browser capture with backend correlation, at the cost of adding one SDK to your app.
Do not use when: you do not control the frontend build.
Mixing paths in one project
You can use more than one path in the same project. A common setup connects a cloud platform account for infrastructure logs and instruments application code with OpenTelemetry for request-level detail. Everything lands in the same searchable set of log records regardless of how it arrives.