Cloud Logging Sources: AWS, Google Cloud, Vercel and More

Last verified on Nov 8, 2026.

Where your code runs decides how its logs get out. Some platforms offer a managed log drain, some offer a stream you aim at a URL, and some give you nothing, so the application or a helper app has to do the shipping. This category lists those paths for each platform Sazabi supports.

Three kinds of path

• Native connection. You give Sazabi limited access to your account and it creates and maintains the forwarding. AWS CloudWatch, Google Cloud, Cloudflare, Vercel, Render and DigitalOcean all offer it. See AWS, Google Cloud and Vercel.
• Endpoint path. You create the log drain or stream in the platform and paste your Sazabi intake URL. This keeps all credentials on your side. Netlify and Render offer it.
• Application or helper. The platform has no log drain, so something you run ships the logs. Railway and Fly.io are the examples: Railway apps send through their OpenTelemetry SDK, and on Fly you deploy a log shipper inside your organization.

What each path costs you

The path decides your constraints, and they are easy to miss until setup day.

• Plan tier. Vercel log drains need Pro or Enterprise, and Hobby and Pro Trial teams cannot create them. Netlify log drains need Enterprise. Cloudflare Logpush is available on every plan since September 30, 2026, and only its Workers trace events dataset needs Workers Paid.
• Scope. Render's endpoint log stream is workspace-wide, so every service in the workspace sends logs. To forward individual services, use the connect path, which sets up a stream per service.
• Cloud bill. On Google Cloud you build the sink, Pub/Sub topic and Collector. GCP bills for Pub/Sub delivery and egress, and a high-volume project can add real cost. Use sink filters to forward only what you need.
• Source of truth. With Railway the data comes from your running app, not from Railway itself, so what you see is what the app chooses to log.

Example: finding the noisy service

A workspace-wide stream sends everything, so the first thing to do after turning it on is count. This command from the Sazabi docs counts lines per service over a day:

sazabi logs ask "how many log lines did each service send in the last 24 hours"

An example result:

checkout-api    41,200
worker-emails   18,900
cron-cleanup   612,000

One service sending ten times the others is almost always a debug flag left on or a retry loop. Fix the source first. If you can't, move to the connect path and exclude that service. With Google Cloud, add a sink filter so those entries never leave GCP.

What to watch across platforms

• Delivery format. Vercel's log drain must use JSON, because NDJSON is not parsed on that endpoint.
• Timestamps. Check that event times are parsed, not just that records arrive. A manual Cloudflare Logpush job needs the RFC3339 format, or events can be stored without a parseable timestamp.
• Gaps after rotation. Tokens, keys and log drains expire or get deleted, and the symptom is silence. Check the Intake page for volume per source each week.
• Account scope. Zone, project and workspace boundaries differ per platform. Write down what each stream covers.
• Two paths to one platform. AWS and Google Cloud have both native and manual sources. Pick one per log group or project to avoid duplicates.

Pick a path per platform

A short checklist before you start:

1. List every platform your code runs on, including the ones that host only cron jobs or previews.
2. For each one, note whether it offers a native connection, a log drain or stream, or neither.
3. Check the plan tier. A log drain that your plan doesn't include costs a day to discover.
4. Decide who owns the intake URL and where it is stored.
5. Run the volume query after enabling each path and compare it with what you expected.

Teams that skip step 5 usually find out about a noisy service from the bill rather than from a search.

Detections

The section below lists the detections Sazabi runs today. Volume checks and deploy-time checks in this page are queries you write. To learn the protocol many of these paths use, read about OpenTelemetry with Sazabi. The Cloudflare page covers edge logs and Workers.