Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

CP Cache Utility: Opening the cache manager times out when the Glide Cached Presets are too big

Open
  • Is something wrong?
#15,623 0 comments 2 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
aws, laravel, php
Domain
backend, performance

Research direction

Start in Statamic\Http\Controllers\CP\Utilities\CacheController::getImageCacheStats(), where the recursive listContents('', true) call walks the Glide cache disk to count files and sum sizes. Reproducing needs an S3-backed Glide cache with many generated presets, so there is no simple local test named in the issue. Done means the Cache page loads without a full synchronous traversal, with the maintainers' choice between caching, async computation or an opt-out settled first.

Written by the indexing model from the issue text.

Description

utilities
Bug description

When opening the Control Panel’s Utilities → Cache page, the request can return a 504 Gateway Timeout.

The Glide cache is configured on an S3 disk. In Statamic\Http\Controllers\CP\Utilities\CacheController::getImageCacheStats(), the cache manager recursively lists the Glide cache contents with listContents('', true) and calculates the file count and total size. This appears to make the page load increasingly expensive as the number of cached images grows.
We have currently 99,636 generated Presets

Observed: 504 at 2026-10-09 06:43:35 GMT; Cloudflare Ray ID: a47b66eb8dd3a9-FRA

How to reproduce

Configure the Glide cache to use an S3-backed disk.
Populate the cache with a large number of generated images.
Open Control Panel → Utilities → Cache.
Actual result: The request GET /cp/traumurlab/utilities/cache returns 504 Gateway Timeout.

Expected result: The cache manager loads without requiring a full synchronous traversal of the remote image cache on every page visit.

Could the Glide cache statistics be cached, computed asynchronously, or made optional? Is there a recommended configuration for using the cache manager with a remote S3 disk?

Logs
Environment
Environment
Laravel Version: 13.34.0
PHP Version: 8.5.8
Composer Version: 2.10.2

Timezone: Europe/Berlin
Locale: de

Locales
Installed: cs, da, de, en, nb, nl, nn
LaravelLang\Lang\Plugin: 15.37.3
Locales Version: 2.11.0
Protected: de, en
Publisher Version: 16.8.0

Livewire
Livewire: v4.4.7

Statamic
Version: 6.34.1 PRO

Statamic Eloquent Driver
Addon Settings: file
Asset Containers: file
Assets: file
Blueprints: file
Collection Trees: eloquent
Collections: eloquent
Entries: eloquent
Fieldsets: file
Form Submissions: eloquent
Forms: eloquent
Global Sets: eloquent
Global Variables: eloquent
Navigation Trees: eloquent
Navigations: eloquent
Revisions: eloquent
Sites: file
Taxonomies: eloquent
Terms: eloquent
Tokens: file

S3-backed Glide cache.
Installation

Fresh statamic/statamic site via CLI

Additional details

No response

Dominant language
PHP
Stars
4.9k
Forks
647
Avg merge
1d 9h
Merged PRs (30d)
102

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from statamic/cms

All issues in statamic/cms

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.