Time to live (TTL)

What is time to live (TTL)?

Time to live (TTL) is a duration that tells a system how long a stored answer can be reused before it should be refreshed. In web operations, TTL appears most often in DNS records and HTTP caching. A DNS TTL tells resolvers how long to keep an address answer. A cache TTL tells browsers, shared caches, or CDNs how long a response can be considered fresh.

TTL is simple in definition and surprisingly easy to mishandle. Too short, and systems keep asking the origin or authoritative service for information they could safely reuse. Too long, and stale information may persist after a deployment, content update, incident, or security change. Good TTL policy balances freshness, performance, resilience, operational control, and privacy.

TTL in DNS and web caching

DNS TTL and cache TTL solve related but different problems. DNS TTL applies before the web request reaches a server. It controls how long resolvers may reuse records such as A, AAAA, CNAME, MX, or TXT answers. Lower DNS TTLs can help planned migrations and failovers take effect faster, although resolvers and clients do not always expire records at the exact moment operators expect.

HTTP cache TTL applies after a response exists. It is normally expressed through response headers such as Cache-Control: max-age=300 or, for shared caches, s-maxage=300. A browser cache, proxy, or CDN can use that value to decide whether a stored copy is still fresh enough to serve without revalidation.

These TTLs are often confused during incidents. Changing a DNS TTL will not purge a CDN cache. Purging a CDN object will not change DNS propagation. Shortening browser cache headers today will not always recall assets that were already cached yesterday with a long TTL. Each layer needs its own plan.

Fresh, stale, expired, and invalidated

A fresh cached response can be served without contacting the origin. An expired response is not automatically useless; it may be revalidated with the origin using validators such as ETag or Last-Modified. If the origin confirms it has not changed, the cache can keep using the stored body and update its freshness. If the origin returns new content, the cache stores the new version.

Stale serving is a deliberate extension of this model. Directives such as stale-while-revalidate and stale-if-error allow some caches to serve an older response while refreshing it in the background or while the origin is unavailable. This can protect user experience during brief origin problems, but it should be used only where serving slightly old content is acceptable.

Invalidation is different from expiry. A purge or content invalidation tells a cache to remove or refresh an object before the TTL naturally ends. Purges are useful, but relying on frequent broad purges often indicates weak URL versioning, unclear content ownership, or a publishing workflow that does not match the cache policy.

Choosing TTLs by content type

There is no universal best TTL. A hashed JavaScript file or image filename can often use a very long TTL because a changed file receives a new URL. A homepage may need a shorter TTL because it changes often and carries editorial or commercial expectations. A product listing may tolerate seconds or minutes of freshness delay, while pricing, inventory, cart, account, and checkout responses need stricter treatment.

Authenticated pages and personalized responses should usually be private to the browser or not stored at all by shared caches. If a response varies by cookie, authorization header, geography, language, device, or experiment assignment, the TTL must be considered alongside the cache key. A long TTL is dangerous if the cache cannot distinguish users or variants correctly.

DNS TTL choices also depend on change frequency and risk. Stable records can use longer TTLs to reduce resolver load and improve resilience. Records involved in migrations, disaster recovery, or traffic steering may need lower TTLs before the change window.

Misconceptions that cause incidents

One common misconception is that no-cache means "do not store." In HTTP caching, no-cache means a stored response must be revalidated before reuse. To prevent storage, use no-store. Another misconception is that the CDN dashboard setting is the only TTL that matters. Application headers, CDN overrides, browser behavior, service workers, and intermediate caches may all influence what users see.

Long TTLs on unversioned assets are another frequent source of pain. If /static/app.js is cached for a year and the same URL is reused for a new build, some users may keep the old script. Versioned or hashed filenames let teams use long TTLs safely because the URL changes when the content changes.

Very short TTLs can be a problem too. A TTL of a few seconds may look safe, but on a busy site it can create high origin request rates, increase tail latency, raise cloud egress costs, and reduce resilience during origin incidents. For pages that change frequently, event-driven purging, revalidation, or narrow route-specific TTLs may be better than making everything nearly uncached.

Security and operational implications

TTL policy has direct security consequences. A shared cache must not reuse private account data, authenticated HTML, session-specific API responses, or security-sensitive error pages across users. If a sensitive response is accidentally cached with a long TTL, the blast radius can grow quickly. Conversely, if security challenge pages, rate-limit responses, or denial responses are cached too broadly, legitimate users may be blocked after the original condition has passed.

Attackers may also target TTL behavior. Randomized query strings can force misses and bypass cached objects. Repeated requests immediately after purges can create thundering-herd pressure on origins. Attempts to poison cache entries become more damaging when the poisoned response has a long TTL and a broad cache key. Strong cache-key design, origin validation, WAF and bot controls, and careful purge workflows reduce these risks.

Operationally, TTL changes should be treated like production changes. Teams need to know who owns headers, CDN rules, DNS records, purge permissions, and rollback steps. A change made in application code can be overridden at the CDN. A change made at the CDN can mask missing headers. Both should be visible in review and in incident timelines.

A practical TTL review process

Start by inventorying routes and record types. For web content, group responses into static versioned assets, public pages, public API responses, personalized pages, state-changing endpoints, admin paths, and error responses. For each group, define whether the response can be stored, by whom, for how long, and whether stale serving is acceptable.

Then check reality. Inspect response headers from production, including examples with and without cookies or authentication. Compare browser behavior, CDN cache status, origin logs, and purge history. For DNS, query from multiple resolvers and confirm the authoritative values match the intended records. Do not assume configuration and observed behavior are identical.

Finally, monitor the outcomes that TTL is meant to improve: cache hit ratio, byte hit ratio, origin request rate, origin latency, DNS error rates, stale response counts, purge frequency, and user-visible freshness complaints. Useful TTL policy is not the shortest or longest duration. It is the duration that lets each route stay fast, correct, recoverable, and understandable when something changes.