# Cache

Every cache operation a recorded request performed: what it asked for, whether it was there, and what it wrote.

![The Cache page in the panel: each key prefix with its store, hit rate, misses, writes and forgets](/images/docs/cache.png)

## What turns it on

Cache operations are collected inside a [request](/docs/telemetry/requests), so `requests.track_requests` is the switch and the application has to accept **Requests**.

## What is recorded

| Field | What it is |
| --- | --- |
| Operation | Hit, miss, write or forget. |
| Store | Which cache store it went to. |
| Key prefix | The part of the key before the first colon. |
| TTL | On a write, how long it was written for. |

## Keys are cut at the colon

Laravel's keys are routinely `prefix:id`, and those two halves are different things: the prefix is the diagnostic part, the id is who the row belongs to. What is stored is the part up to the first colon, and a key with no colon is truncated.

```php config/larabug.php
'capture_cache_keys' => env('LB_REQUEST_CAPTURE_CACHE_KEYS', false),
```

Turn it on to keep whole keys, up to 255 characters, when the id is the thing you are chasing.

## What it answers

A hit ratio is only interesting per endpoint. A page that misses the same key on every request has a cache that is not working, and reading that against the same request's [queries](/docs/telemetry/queries) is usually the whole diagnosis: the misses and the query they cause are in the same waterfall.

`max_cache_events` keeps a hundred operations per request, with the counters running past it.