Skip to main content
This guide goes in order. Each step rules something out, so work down rather than jumping.

​
Start with describe

That is the whole picture: status, the generated hostname, each custom hostname with its progress, routes and their origins, traffic protection, and basic auth. Two things to read carefully. Status conditions report on several hostnames at once and name none of them. A load balancer reporting a partial failure is telling you something is wrong with at least one hostname, not which. The per-hostname lines below are where the answer is. “Published” is not “serving”. A load balancer reports its configuration as published within seconds of a change, while Datum’s edge is still catching up, and nothing publishes when that finishes. There is no documented figure for how long, so do not wait on a number — make a request.

​
Is anything actually reaching it?

Test the generated hostname first. It bypasses every question about your own DNS, so it splits the problem cleanly:
  • Generated hostname works, custom one does not → a hostname problem, below.
  • Neither works → the load balancer or its origin, further below.
No traffic in the logs is not a diagnosis. A load balancer nobody has called looks exactly like one that is broken. If nothing is arriving, send a request yourself and look again.

​
A hostname that does not work

describe shows four steps per custom hostname. Work on the first one that is not done and ignore the rest — each gates the next. Two states that look like failures and are not:
  • Datum does not manage the domain’s DNS. Reported as such, set deliberately. It means “create a CNAME yourself”, not “something went wrong”. Nothing is pending.
  • The generated hostname reports nothing about its DNS record. No status is published for it at all, so its absence tells you nothing either way.

​
An origin that cannot be reached

If the generated hostname does not serve either, the problem is between the load balancer and your origin.
Read the response codes: The response flags in -o wide are the most useful field when nothing else explains it — they say whether the connection to your origin failed, timed out, or found nothing healthy. For a network service origin, check the service exists and declares the port name you used. --port takes a name like http, never a number, and Datum will not invent a service that does not exist.

​
A change that was accepted and never took effect

This one is easy to miss. If a load balancer reports as waiting to be published, read the message rather than waiting. A message saying it cannot be published means Datum has decided it cannot use these settings at all — the load balancer keeps serving whatever it published last, and waiting will never clear it. To read the message, run datumctl alb describe my-app. It names the setting that Datum can’t use. Fix that setting, and Datum publishes the change.

​
Nothing reports a fault and it still does not work

In rough order of likelihood:
  1. Nothing points at it. No CNAME, no custom hostname attached. Common, and invisible in status.
  2. It was created moments ago. The edge is still converging. Retry the request rather than reading status again.
  3. The origin is still starting. A new Compute Instance can report Available a minute or two before the app inside it listens. The load balancer returns 503 until it does.
  4. The origin is refusing connections. The logs show it; status does not.
  5. Traffic protection is blocking real requests. Enforce at a high sensitivity will do this.

​
It works from one place and not another

Each client reaches the Datum location nearest to it, and Envoy in that location serves the request. If a load balancer behaves differently for users in different regions:
  1. Find which location you reach. Visit edge.datum.net from the affected network. It shows the Datum location your traffic arrives at.
  2. Check whether a change is still rolling out. Each location applies a change on its own schedule. If you changed the load balancer moments ago, wait briefly and try again.
  3. For a Compute origin, check where your Instances run. Envoy prefers an Instance in its own location. If that location has no healthy Instance, Envoy sends the request to the nearest location that has one, which adds latency for users near the empty location. Run datumctl compute workloads describe WORKLOAD_NAME to see the health of the Instances in each location. See Placement and scaling.
  4. For a public origin, test it from that region. Envoy connects to a public origin over the internet from the location that received the request. An origin that blocks or rate-limits some regions or IP ranges can fail from one location and work from another.

​
Permission errors

A command that fails with a permission error rather than a not-found means your account cannot act on that resource in this project. Ask whoever administers the project; there is nothing to change on the load balancer.
Last modified on October 23, 2026