More context: We can clearly see that there are no logs in the screenshot between the Redis Rate Limits logs and my manual service restart

those redis logs just show a normal background save , it completed successfully in 100ms. redis didn't restart (you'd see "server initialized" or "ready to accept connections" if it did)

the real issue is your api service , notice the 3 hour gap in logs then "starting container" for blitz-api. something made your api unresponsive

to figure out what actually happened, check:

• railway metrics for both services during that time window (cpu/memory graphs)

• does your api have connection retry logic for redis?

• any error logs from your api right before 07:43?

could be a connection leak, timeout issue, or your rate limiting code not handling the brief redis save operation well. but need more logs/metrics to say for sure what made the api hang

redis itself looks fine from what you posted

Thanks for your response, here are more informations like you asked. I create my connection to the redis Rate Limit service on startup in the API service and there is autoReconnect on true (default) (using bun's redis client https://bun.com/docs/runtime/redis), like: const client = new RedisClient("redis://username:password@localhost:6379"); (using railway variable REDIS_URL to connect to redis)

Looked at our Otel and logs in Axiom and there is also a gap (nothing between) like in railway.

I might be wrong but a save operation should not impact active connections ?

API service metrics (spike started around ~7:43 (can't have exact time):

Rate Limit Redis metrics:

Rate Limit Redis metrics:

Redis config:

Logs timeline, no errors before, everything was normal (200 statuses):

Logs before the db save (everything looked normal - status 200):

Bump, I'm still looking to figure out what happened