Dash0 applies rate limits to its HTTP API to keep the platform stable and to share capacity fairly across organizations. This page explains how the limits work, what a rate-limited response looks like, and what to do if you hit one.

These request-rate limits are separate from the limits on telemetry data and configuration objects (such as spans per trace or dashboards per dataset). For those, see Understand Telemetry Ingestion Limits.

How Rate Limiting Works

Dash0 counts your requests over a rolling time window and rejects further requests once a limit is reached, until enough of the window has elapsed for capacity to free up.

Limits are applied along two dimensions at the same time:

Per user — requests attributed to your individual user identity.
Per organization — requests across everyone in your organization.

A request is rejected as soon as either the per-user or the per-organization limit is reached, whichever comes first. The per-organization limit is the higher of the two, so an individual user normally meets their own limit before contributing to organization-wide exhaustion.

Rate Limit Tiers

Requests are classified into one of three tiers, and each tier has its own independent budget. This means heavy read traffic does not consume the budget available for writes, and vice versa.

Tier	Applies to	Typical operations
Read	Read-only requests	Querying spans, logs, metrics, traces, dashboards; running PromQL/queries; listing resources
Write	Requests that create, update, or delete	Saving dashboards, check rules, notification channels, and other configuration
Test	Endpoints that send a test signal	"Send a test notification" and similar validation actions

The tier is determined automatically from the request. You do not need to set anything.

Default Limits

The table below shows representative default limits. Actual limits vary by plan and region, and can be raised on request — treat these as a baseline rather than a contract.

In particular, some regions run limits substantially higher than the values below — in some cases several times the Read figures shown here. If the X-RateLimit-* headers on your responses report a higher limit than this table, that is expected, not a bug. The headers are always the authoritative source of your current limit at any moment (see below); the table is only a rough orientation.

Tier	Per user	Per organization	Window
Read	4,000 requests	8,000 requests	10 seconds
Write	1,000 requests	2,000 requests	5 minutes
Test	10 requests	20 requests	1 minute

Read limits are deliberately high because dashboards and explorers issue many concurrent queries. Write and Test limits are lower because those operations are less frequent in normal use.

Limits for the Dash0 CLI and Dash0 Terraform Provider

Requests authenticated with an API token (rather than an interactive session), such as via the Dash0 Terraform Provider and Dash0 CLI, are subject to an additional per-token limit. This applies on top of — not instead of — the per-user and per-organization limits above: a token-authenticated request can be counted against both, and in practice the per-token limit is usually the one you reach first.

The per-token limit is tuned for the bursty nature of infrastructure-as-code workflows. A single terraform apply may issue many writes in quick succession, so the token budget allows a burst of requests up to a maximum, then refills steadily over time. As long as your sustained rate stays within budget, short bursts are absorbed without error.

These limits use the same Read and Write tiers as above; there is no separate Test tier for token-authenticated traffic (test calls count as writes).

Rate Limit Response

When a request is rejected, Dash0 returns HTTP 429 Too Many Requests with a JSON body of this shape:

json

1234567
{
  "error": {
    "code": 429,
    "message": "rate limit exceeded",
    "traceId": "<trace ID for this request>"
  }
}

The code is always 429 and a traceId is always present; the exact message text may vary slightly depending on which endpoint rejected the request. The traceId is useful when contacting support about a specific rejection.

Rate Limit Headers

Every response that passed through the rate limiter — both successful responses and 429s — includes these headers, so you can pace yourself before hitting a limit:

Header	Meaning
`X-RateLimit-Limit`	The maximum number of requests allowed in the current window.
`X-RateLimit-Remaining`	How many requests you have left in the current window.
`X-RateLimit-Reset`	The Unix timestamp (in seconds) at which the limit resets to full.

When both a per-user and a per-organization limit apply, these headers reflect the more restrictive of the two — the one you are closest to exhausting.

`Retry-After`

On a 429 response, Dash0 may also include a Retry-After header indicating how many seconds to wait before retrying. When present, it already accounts for refill time plus a small random offset to avoid retry storms. Prefer Retry-After over a fixed retry delay whenever it is present.

Handling Rate Limits

A few practices keep well-behaved clients comfortably under the limits:

Read the headers and self-pace. Use X-RateLimit-Remaining and X-RateLimit-Reset to slow down as you approach a limit, rather than waiting to be rejected.
Honor Retry-After. When a 429 includes it, wait at least that long before retrying.
Back off exponentially. If Retry-After is absent, retry with increasing delays (for example 1s, 2s, 4s) plus a little jitter, rather than retrying immediately in a tight loop.
Batch and deduplicate. Combine related changes where the API supports it, and avoid issuing redundant reads.
Spread out bulk work. For large imports or migrations via the CLI or Terraform, expect short bursts to be absorbed but pace sustained throughput.

Requesting Higher Limits

If you have a legitimate need for higher limits, for example a large Terraform-managed configuration, a high-traffic dashboard deployment, or a bulk migration, limits can be raised for your organization.

Contact Dash0 support and include:

Your organization's name or identifier.
Which tier you are hitting (Read, Write, or Test) and whether it is via the API, CLI, or Terraform provider.
A traceId from a recent 429 response, if you have one.

This page covers request-rate limiting only. Other protections and limits in Dash0 are documented separately:

Telemetry and configuration quotas — limits on the data you ingest (spans, logs, metrics) and on configuration objects (check rules, dashboards). See Understand Telemetry Ingestion Limits.
Website monitoring client-side limits — browser instrumentation rate-limits the events it sends before they ever reach the API. These are also covered in Understand Telemetry Ingestion Limits.

Understand HTTP Rate Limits