Framework activity
Separate cache behavior from direct Redis work
Use Cache for Laravel’s cache abstraction and Redis for direct client commands, then trace keys, stores, results, failures, timing, and source without counting the same operation twice.
Choose the section by API
Cache records operations emitted by Laravel’s cache system, regardless of the selected cache driver. Redis records commands made through the Redis client. When a Redis-backed cache operation also emits a low-level command, New Debug Bar removes the duplicate Redis entry.
Inspect cache operations and results
Review reads, writes, deletes, flushes, stores, drivers, tags, key evidence, duration, failure state, and application source. Open unusual operations such as a full flush or repeated write before judging the total count.
- A hit shows that the selected store returned a cached value.
- A miss shows that the app had to continue without that cached value.
- A failed read or write is different from a normal miss and should be traced to its store and source.
- A flush clears the selected store broadly; confirm that the source intended that scope.
Treat a high miss rate as a lead
By default, a high-miss finding needs at least five cache reads and an 80% miss rate. The minimum avoids warning about one small lookup; the rate highlights repeated work that may not be benefiting from caching.
Confirm that the keys are expected to be warm, the correct store and tags are used, TTLs are appropriate, and no earlier source flushes or forgets them. A first request after a deliberate cache clear can have a valid high miss rate.
Inspect direct Redis commands
The Redis section keeps command, connection, bounded key evidence and parameters, timing, failure state, and the application call site. Results and error details are bounded and redacted before storage.
Use the source to distinguish an intentional pipeline, lock, rate limiter, pub/sub action, or application data structure from accidental repeated commands. A slow command needs database-side context as well as local duration.
Choose exact keys or stable hashes
The default key_policy is full, which keeps bounded exact cache keys, Redis keys, and cache tags for private local debugging.
Set NEWDEBUGBAR_KEY_POLICY=hash when stable matching is enough. Hashed evidence lets you recognize repeated use without retaining the original key.
Next step
Review retained local values
See how capture-time policies, collection limits, storage, browser access, and MCP access apply to keys and other profile data.
Open data and privacy