How data gets into Sazabi

Everything you investigate in Sazabi starts as data you send in. There are two ways to set up a log source: use Native to connect a supported platform account and let Sazabi configure forwarding, or use Manual to configure a collector, SDK, or agent to send to your log source’s intake URL. This page covers how ingestion works and how to choose a path; the rest of the section covers sending frontend, mobile, metrics, and trace data.

​

How ingestion works

You send data to Sazabi’s intake URL — the keyed endpoint tied to a log stream, with the shape https://<key>.<region>.intake.sazabi.com. Copy the whole URL and point your sender at it; because your public key is embedded in the hostname, the URL authenticates the request on its own — there is no separate key or header to send. Sazabi normalizes what arrives — logs, metrics, traces, and webhook events — into a single searchable body of log records that the Sazabi agent queries during an investigation. You get the intake URL from Settings > Log streams: open your log source and copy the Intake URL from its setup screen. The public key embedded in it is a low-level credential most customers never handle directly — it lives under Settings > Public keys for advanced use.

​

Everything is a log

Sazabi treats every kind of telemetry as a log. You do not run a separate pipeline per signal type: one intake accepts your data, normalizes it, and stores it as searchable log records. That means one setup path and one place the agent looks when you ask a question.

• Metrics arrive as OpenTelemetry metrics (or Prometheus metrics relayed through an OpenTelemetry Collector), and each data point becomes a searchable record with its labels and values. See Send metrics.
• Traces arrive as OpenTelemetry traces and are stored as records the agent can search and correlate with your logs by trace context. See Send traces.
• Webhook events — deployment notifications, alerts from other tools, and similar signals — arrive at the same intake and become records you can search. See Webhook events source.

Because each signal becomes a searchable record, the agent can query logs, metrics, traces, and events in one investigation. Trace identifiers, metric labels, and structured log fields preserve signal-specific context.

​

Two ways to set up a log source

Pick by where your data lives.

• Native — connect your account — authorize a supported platform account and let Sazabi configure forwarding. Use this when your platform is in the catalog’s Connect-your-account list (for example Vercel, Cloudflare, or Sentry).
• Manual — send to an endpoint — point a collector, SDK, or agent at your project’s intake URL. Use this when you run your own collectors, instrument application code, or your platform is not in the connect-your-account list.

Both modes can stream logs continuously. Manual setup gives you control over the sender and forwarding configuration; it does not mean sending logs by hand.

​

Choose a path

For most projects, start by checking whether your platform is in the connect-your-account list; it is the least setup.

​

Native versus manual

The difference is who configures delivery, not how often logs arrive. Both modes can stream logs continuously. Choose native when Sazabi supports your platform and you want it to configure forwarding. Choose manual when you already operate a sender, instrument application code, or want control over what you forward. Some platforms support both modes.

​

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 native setup. You authorize Sazabi once and it configures log forwarding — 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. Use manual setup with 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. Use manual setup 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 manual setup with 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.

​

Browse the log source catalog

Every supported source is documented per vendor in the log source catalog, split by the same two paths. Start there to find your platform and its exact setup steps.

​

In this section