Logs & monitoring

P2Lab Cache keeps three optional logs — invalidation, reverse-proxy and warmup history. All three are off by default to keep the database lean; enable the ones you care about while diagnosing or while tuning your invalidation strategy.

Invalidation log

Records every local-cache purge. Enable from Settings → Speed Boost → Core → Settings → Enable Invalidation Log.

What each entry contains:

Timestamp
Triggering entity — type, ID, number, name (when available)
Triggering event — entity.written, product.indexed, manual clear-all, CLI, API call, etc.
Changed fields (Smart mode only) — the field-level diff that caused the analyzer to produce this tag set
Tag set — the tags that were purged
Cache entries purged — count

Browse from Speed Boost → Invalidation log → List. Click a row to see the full detail page.

Old entries are deleted automatically by the cleanup-invalidation-log scheduled task after 30 days — see Scheduled tasks.

Use cases

“Why was my entire cache cleared yesterday at 14:32?” — open the invalidation log filtered to that time.
“Why is this product page always MISSing?” — search the log for the product number, see what’s invalidating it.
“I’m seeing way more purges than expected” — sort by entity type, find the chatty one.

Reverse-proxy log

Records every xkey purge sent to Varnish. Enable from Settings → Speed Boost → Reverse proxy → Settings → Enable Reverse Proxy Log.

What each entry contains:

Timestamp
Operation — purge / ban
URL or tag set sent to Varnish
HTTP status Varnish responded with
Response time
Triggering entity — type, ID, number (when known)

Browse from Speed Boost → Reverse-proxy log → List.

Two specialised views complement the list:

Entity timeline

Reverse-proxy log → List → row → Entity timeline (also reachable directly when you know the entity). Shows every xkey purge that a specific entity has triggered, in chronological order. Useful for “this product seems to be purging too much”.

URL flow

Reverse-proxy log → List → row → URL flow. Shows every purge that has affected a specific URL, and which entity caused each one. Useful for “this URL is always cold; who keeps purging it?”.

Old entries are deleted automatically by the cleanup-reverse-proxy-log scheduled task after 30 days.

Warmup history

Always recorded — no toggle. Browse from Speed Boost → Warmup history → List. Each row is one warmup run with:

Started / finished timestamps
Total / checked / failed counts
Average HTTP response time
Status (running / paused / cancelled / completed)
Sales-channel scope

The detail view lists individual failed URLs with their HTTP status code.

Cache entries table

Not strictly a “log” but useful for diagnosis: Speed Boost → Cache entries → List shows every cache entry currently stored in the database. Per row:

URL
Type (product / category / listing / cms / buybox)
Sales channel
Original size / cached size / compression ratio
Generation time / cache-hit time
Last seen

You can search by URL prefix and clear individual entries from this view.

Debug headers

When Core → Settings → Debug Mode is on, every response carries:

X-P2Lab-Cache-Status: HIT | MISS
X-P2Lab-Cache-Generation-Time: <seconds>

Combine these with the logs above for the full picture: the header tells you whether a request was cached, the log tells you why.

Cleanup tasks

Three scheduled tasks keep the log tables from growing forever:

p2lab_cache.cleanup_cache_entries — runs nightly, drops orphaned p2lab_cache_entry rows that no longer exist in the backend
p2lab_cache.cleanup_invalidation_log — runs nightly, drops rows older than 30 days
p2lab_cache.cleanup_reverse_proxy_log — runs nightly, drops rows older than 30 days

Make sure your messenger:consume scheduler worker is running, or these don’t fire. See Scheduled tasks.