Latency

GET/api/v1/latency

Reads history from multiple External Latency Agents to one public TCP target. Cloudflare's own latency is not in this response; use Status or Checks.

Query parameters

Parameter	Required	Default	Range	Purpose
target_id	yes	—	public TCP target ID	probed target
hours	no	24	1–168	history window

curl -fsSL 'https://YOUR-API/api/v1/latency?target_id=vps-a&hours=24'

Response structure

{
  "ok": true,
  "target_id": "vps-a",
  "sources": [
    {
      "id": "home-shanghai",
      "name": "Shanghai Telecom",
      "kind": "external",
      "points": [
        {
          "checked_at": 1760000000,
          "latency_ms": 28.4,
          "ok": true
        }
      ]
    }
  ]
}

sources[]

Each source is a latency node created in the admin panel that has actually submitted results. Creating the record produces no data; the node enters history only after its install command completes the first submission.

When target_id is missing, the target does not exist, or is disabled, the compat implementation may return HTTP 200 with ok: false and error. Clients must check JSON ok.

latency_sources in Status keeps only the latest sources inside the stale window; this endpoint returns history within hours. "Old points in history but no node in the legend" usually means the node stopped reporting.

Troubleshooting order

If the frontend only shows Cloudflare:

1. Check the node is enabled with a recent "last report" in the admin panel.
2. Check systemd and journal on the node.
3. Run --once manually and confirm accepted > 0.
4. Confirm the target is an enabled public TCP target without hidden address.
5. Wait for the short status cache to refresh, then check sources here.

New install commands make the installer clean up old processes; merely restarting an old node may keep using stale scripts, node IDs, or tokens.

Default cache is 30 s with target_id and hours in the key. Only external sources are returned; Cloudflare current latency comes from Status and history from Checks.