Documentation

Time To Become Readable

Time To Become Readable (TTBR) is the delay between when you write data to InfluxDB Cloud and when that data becomes queryable. TTBR is variable and is affected by many factors.

How write requests work in the InfluxDB Cloud API

Whenever you send a write request to the /api/v2/write endpoint, the following actions occur:

  1. API validates the request and queues the write.
  2. If the write is queued, API responds with an HTTP 204 status code.
  3. API handles the write asynchronously and reaches eventual consistency.

For more information, see /api/v2/write documentation.

The returned 204 status code does not mean that the point is queryable; it means the write request has been added to the durable write queue (for more information, see Handle write and delete responses). TTBR represents the time it takes for the write request to be queued, the write operation to be executed, and the data to become queryable.

For more information about status codes returned from the /api/v1/write endpoint

Flux vs InfluxQL

One of the primary factors that affects TTBR is the query language you use to query the newly written data. InfluxQL queries use a metadata cache that stores information about fields and series.

If you write a point with a new field, the new field will not be queryable by InfluxQL until InfluxDB Cloud refreshes the metadata cache, which can take up to 15 minutes. Flux does not rely on the metadata cache, so the newly written data should be queryable in approximately one second.

If you write a point with an existing field, and the field already exists in the metadata cache, both InfluxQL and Flux should be able to query the new data in approximately one second.

InfluxDB Cloud TTBRs

Write request toFluxInfluxQL
Existing field≈1s≈1s
New field≈1s≈10m to 15m

Was this page helpful?

Thank you for your feedback!


InfluxDB 3.9: Performance upgrade preview

InfluxDB 3 Enterprise 3.9 includes a beta of major performance upgrades with faster single-series queries, wide-and-sparse table support, and more.

InfluxDB 3 Enterprise 3.9 includes a beta of major performance and feature updates.

Key improvements:

  • Faster single-series queries
  • Consistent resource usage
  • Wide-and-sparse table support
  • Automatic distinct value caches for reduced latency with metadata queries

Preview features are subject to breaking changes.

For more information, see:

Telegraf Enterprise now in public beta

Get early access to the Telegraf Controller and provide feedback to help shape the future of Telegraf Enterprise.

See the Blog Post

The upcoming Telegraf Enterprise offering is for organizations running Telegraf at scale and is comprised of two key components:

  • Telegraf Controller: A control plane (UI + API) that centralizes Telegraf configuration management and agent health visibility.
  • Telegraf Enterprise Support: Official support for Telegraf Controller and Telegraf plugins.

Join the Telegraf Enterprise beta to get early access to the Telegraf Controller and provide feedback to help shape the future of Telegraf Enterprise.

For more information:

Telegraf Controller v0.0.6-beta now available

Telegraf Controller v0.0.6-beta is now available with new features, improvements, and bug fixes.

View the release notes
Download Telegraf Controller v0.0.6-beta

InfluxDB Docker latest tag changing to InfluxDB 3 Core

On May 27, 2026, the latest tag for InfluxDB Docker images will point to InfluxDB 3 Core. To avoid unexpected upgrades, use specific version tags in your Docker deployments.

If using Docker to install and run InfluxDB, the latest tag will point to InfluxDB 3 Core. To avoid unexpected upgrades, use specific version tags in your Docker deployments. For example, if using Docker to run InfluxDB v2, replace the latest version tag with a specific version tag in your Docker pull command–for example:

docker pull influxdb:2

InfluxDB Cloud powered by TSM