TTL (Time To Live) is how long a cached copy lives on an edge node. A longer TTL means a higher hit rate and fewer origin fetches; but after content updates, stale copies also linger longer. Setting the right TTL per content type is the key to balancing "fast" against "fresh".
What TTL is
When an edge node caches a copy, it also records when it expires. Requests within the TTL are served straight from the edge; past the TTL, the node revalidates with or re-fetches from the origin. TTL expiry doesn't mean the content has definitely changed — it just triggers a "should this update" check.
Value range
The cache time is at least 1 second and cannot be 0. If you want a class of content to bypass caching entirely, use the "no cache" policy rather than setting the TTL to 0 — the latter is not the correct way to express "don't cache", and the system does not accept a value of 0.
- Static assets (images, fonts, etc.) can take a long TTL, such as a day or more.
- Occasionally-updated pages can take a few to tens of minutes, balancing hit rate and freshness.
- Don't rely on an extremely short TTL for real-time content — the no-cache policy is more reliable.
Different TTL per content type
In cache rules, each rule can specify its own TTL. We recommend tiering by how often content changes: long TTL for the near-static, medium for the occasionally-changed, short or no-cache for the frequently-changed. This maximizes hits while keeping the window for stale content within an acceptable range.
Relationship with origin Cache-Control
If origin responses carry caching headers such as Cache-Control, you can choose to have the edge follow the origin, or let veilx rules override uniformly. Origin headers are convenient for central management shipped with the content; platform rules are convenient for quick tweaks in the console. Pick one as primary to avoid the two fighting each other.