---
name: azion-check-the-cache-status-of-a-response
description: >-
  Send one request with a debug header and read whether Azion served the response from its cache, together with the key the copy is stored under.
---

# Check the cache status of a response

You check whether [Cache](/en/documentation/platform/applications/#cache) served a response from a stored copy by requesting the object with a debug header and reading two response headers. The check runs from any machine with `curl`, and it needs no change to the application.

The same response carries the cache key the copy is stored under, which is the argument a cache key purge takes. For the key format and every status value, refer to [Cache keys](/en/documentation/platform/applications/cache/cache-keys/).

---

## Prerequisites

- `curl` on your machine.
- The URL of an object your application serves.

---

## Request the debug headers

The request header `Pragma: azion-debug-cache` makes Azion return the cache state of the response. To read it:

1. **Request the object with the debug header**

   The `-I` flag asks for the response headers alone, so the body is not downloaded:

   ```bash
   curl -sI -H "Pragma: azion-debug-cache" https://www.example.com/static/site.js
   ```

2. **Read the cache status**

   The `x-cache` header carries three values: the cache status, the IP address of the server that answered the request, and the protocol. Under HTTP/2, the header names arrive in lowercase:

   ```http
   x-cache: MISS from 192.0.2.10 with HTTP/2.0
   x-cache-key: httpswww.example.com/static/site.js
   ```

3. **Read the cache key**

   The `x-cache-key` header carries the key the copy is stored under. A cache key purge takes that value as its argument.

4. **Run the same command again**

   Compare the status of the second response with the first.

You now know whether the response came from the cache, from the origin, or was not cached at all.

In the [Build and run marketing websites](/en/documentation/use-cases/build-and-run-applications/build-and-run-marketing-websites/) use case, expect:

- **Pages answer from cache.** The second request for a page, such as `/about/`, carries `x-cache: HIT`. The first can carry `MISS`, while Azion reads the page from the bucket.

In the [Deploy frontend applications](/en/documentation/use-cases/build-and-run-applications/deploy-frontend-applications/) use case, expect:

- **Interface files come from cache.** The second request for a script of the build, sent with the `Pragma: azion-debug-cache` header, carries `x-cache: HIT`. Its path is in a `<script>` tag of the entry HTML. For how to read the header, refer to [Read the status](#read-the-status).

In the [Accelerate websites and APIs with a CDN](/en/documentation/use-cases/improve-performance-and-reliability/accelerate-websites-and-apis-with-a-cdn/) use case, expect:

- **Static files answer from cache.** The second request for `https://www.example.com/static/app.css` carries `x-cache: HIT`. The first can carry `MISS`, while Azion fetches the file.
- **Pages answer from cache.** The second request for the home page carries `x-cache: HIT`.

---

## Read the status

`HIT` means the response was served from a stored copy and the origin was not asked. `MISS` means the object was not in the cache, so Azion fetched it from the origin and may store the response for later requests. A `-` in both headers means the content is restricted from caching.

The other values a response can carry are `EXPIRED`, `STALE`, `UPDATING`, `REVALIDATED`, and `BYPASS`. For what each one means, refer to [Cache keys](/en/documentation/platform/applications/cache/cache-keys/).

A `-` on a `POST` or `OPTIONS` request means caching is off for that method. To turn it on, refer to [Cache POST and OPTIONS responses](/en/documentation/guides/application-performance/cache-and-purge/cache-post-and-options-responses/).

In the [Protect public APIs from abuse](/en/documentation/use-cases/secure-applications-and-networks/protect-public-apis-from-abuse/) use case, expect:

- **Cacheable responses do not reach the origin.** Request a route your cache setting covers twice, with the `Pragma: azion-debug-cache` header. The second response carries `x-cache: HIT`.

---

## Next steps

- [Cache keys](/en/documentation/platform/applications/cache/cache-keys.md): The key format, every variation it can carry, and all eight cache status values.
- [Troubleshoot Applications](/en/documentation/platform/applications/troubleshooting.md#cache): What to check when a response carries no status, or stays MISS on every request.
- [Purge cached content](/en/documentation/guides/application-performance/cache-and-purge/purge-cached-content.md): Remove the copy this key names, before its TTL ends.
- [Expiration and freshness](/en/documentation/platform/applications/cache/expiration-and-freshness.md): Why a request is answered from a copy, from the origin, or not cached at all.
- [Build and run marketing websites](/en/documentation/use-cases/build-and-run-applications/build-and-run-marketing-websites.md): A marketing site served from Object Storage through Cache and purged after each deploy.
- [Deploy frontend applications](/en/documentation/use-cases/build-and-run-applications/deploy-frontend-applications.md): A single-page application whose API calls reach an existing backend under the same domain.
- [Accelerate websites and APIs with a CDN](/en/documentation/use-cases/improve-performance-and-reliability/accelerate-websites-and-apis-with-a-cdn.md): Two cache settings, one with Tiered Cache, that serve a site's static files and pages near its users.
- [Protect public APIs from abuse](/en/documentation/use-cases/secure-applications-and-networks/protect-public-apis-from-abuse.md): An API whose rate limit runs last, after WAF, a token check, and Bot Manager.