On a Redis cache store, php artisan cache:clear sends FLUSHDB, which deletes every key in the selected Redis database. The cache prefix plays no part, so the command also deletes keys that other applications keep in that database.
The Laravel documentation warns about this under Cache::flush(): flushing ignores the configured prefix and removes all entries, which matters when the cache is shared. In the framework source, the Redis store’s flush() method is one call to flushdb() on its connection. Redis documents FLUSHDB as removing all keys from the current database, and the command takes no key pattern.
How it shows up
I met it on a server where two Laravel applications kept their cache in the same Redis database. Every deploy ran cache:clear. After a deploy of one application, the queue and scheduler health checks of the other failed until its scheduler ran again, about a minute later. Those checks read heartbeat keys from the cache, and the deploy next door had just deleted them.
A different prefix per application only changes the key names. The damage is larger when a cache store points at the database that also holds queued jobs or sessions, because FLUSHDB takes those too. I found one application configured that way.
Give each application its own database number
A new Laravel application already separates its own data. Its cache connection defaults to database 1. Its default connection, which the Redis queue uses, defaults to database 0. Two applications with those defaults on one server still share both, so I gave each application its own cache database in .env. In a current Laravel skeleton the variable is REDIS_CACHE_DB:
REDIS_CACHE_DB=4Then I check what the application reads, because the variable name in .env may not be the one the code uses. An application created before Laravel 11 that still has its original config/cache.php selects its cache store with CACHE_DRIVER, so a CACHE_STORE line in its .env does nothing.
php artisan config:show cache
php artisan config:show databaseOn the Redis side, the keyspace section prints one dbN line for each database that holds keys:
redis-cli INFO keyspaceAfter the change, each application’s cache sits under its own number, and a cache:clear in one leaves the other’s key count alone.
Database numbers exist only on a standalone Redis. Redis Cluster has a single database, 0, so FLUSHDB there empties everything and the separation has to be a different instance.