Agent said:

Let me check the deploy logs around 15:06 to see what triggered the sleep:

Searched deploy logs: sleep

Hide result

No logs found

Let me check the HTTP traffic logs around that time to confirm there was actually traffic:

Searched HTTP logs

The HTTP logs are empty because tokenizer-db is a Postgres database—it uses TCP, not HTTP. The sleep detection might not be properly tracking TCP traffic on port 5432.

This looks like a Railway platform issue where the sleep feature isn't correctly detecting activity on non-HTTP services. I'd recommend:

1. Report this to Railway support with the details: tokenizer-db went to sleep at 15:06 despite active TCP traffic on port 5432

Serverless is best effort in the sense that we can't guarantee it will wake/sleep at exactly the right time. If you're looking for consistent, I would recommend just keeping the replica active

Ok but this is a situation in which there was constant traffic when the service went to sleep. If your systems can see the constant traffic, why was a sleep triggered?

Serverless is best effort, meaning we can't guarantee it will wake or sleep at exactly the right time. If you need consistent availability, we'd recommend keeping the replica active rather than relying on serverless.

I understand that it must be difficult to get it to wake or sleep at exactly the right time, but this is a situation in which my service was sending and receiving traffic constantly, for many minutes, and went to sleep. It seems to me there was plenty of time and information to indicate that the "sleep after 10 minutes of inactivity" timer should be reset.

I'm sorry, but our previous statements stand correct. If you want to avoid disruptions, disable serverless.