Monitor DigitalOcean with Sazabi

Last verified on Nov 8, 2026.

On DigitalOcean App Platform you describe an app as a spec: services, workers, jobs, static sites and functions. DigitalOcean builds, deploys and scales those components for you. Its dashboard shows basic logs. When you need history, search across components or a view next to the rest of your stack, the logs have to go somewhere else.

Sazabi is AI-native observability and security. For App Platform it receives your apps' runtime logs through a log destination that points at a Sazabi intake URL.

What Sazabi reads from DigitalOcean

DigitalOcean's app spec has a log_destinations object, and App Platform can forward runtime logs to Managed OpenSearch, OpenSearch, Datadog and Better Stack. Sazabi uses the Datadog-compatible type, with your intake URL as the endpoint. DigitalOcean notes that forwarding does not count toward an app's bandwidth usage (DigitalOcean: Forward logs).

The connected-account path does the spec change for you. Sazabi fetches the current spec for each app you select, adds the destination to every service, worker and job, and updates the app. That needs a personal access token that can write app specs. The manual path is the same destination added by hand under Settings > Log Forwarding in the app, followed by a redeploy.

The agent can also run doctl in its sandbox if you add the DigitalOcean CLI connection with a DIGITALOCEAN_ACCESS_TOKEN.

Questions it answers

• Which component of this app logged the error, the web service or the worker?
• Did the job run, and what did it print before it exited?
• Did the first error show up right after a deployment?
• Are two apps logging the same upstream failure?
• Which apps are forwarding, and which ones are silent?

A worked example: the app that forwards everything except one component

The destination is added to the components that run your code. Static sites and App Platform Functions do not take it, so a spec can look healthy and still leave one component dark. This is what the destination looks like once added to a service in the spec, with fictional values:

services:
  - name: api
    log_destinations:
      - name: sazabi
        datadog:
          endpoint: https://example-key.intake.example.com
          api_key: example-public-key
workers:
  - name: queue-consumer
    log_destinations:
      - name: sazabi
        datadog:
          endpoint: https://example-key.intake.example.com
          api_key: example-public-key

The api service and the queue-consumer worker carry a destination. A Functions component named webhooks in the same app would not. Check what actually arrives:

sazabi logs ask "Which DigitalOcean components sent logs in the last hour? List each component name with its record count."

If webhooks is the one missing from the results, that matches the spec. App Platform Functions use a different configuration path, so send them through the OpenTelemetry endpoint. If queue-consumer is missing, check whether the destination was removed from the spec or the token was revoked, and redeploy the app after fixing it.

Constraints from DigitalOcean

DigitalOcean says dedicated egress IP addresses cannot be used for log forwarding. If your destination needs a fixed source address, that matters for you. Log forwarding also needs the app spec to be complete when you update it through doctl or the API, because the spec must define all of the app's settings. Download the current spec first, then add log_destinations, instead of writing a partial one.

How it fits with other integrations

App Platform competes with and sits next to other managed platforms. See Render, Railway and Fly.io, or browse the cloud platforms category. Droplets and other DigitalOcean resources go through the OpenTelemetry integration, and the full list is on the integrations page.