15 days ago
Hi guys,
I’ve been experiencing a strange issue for the past 2–3 weeks.
Sometimes, when I deploy, it seems like I’m getting a “bad” server. I regularly monitor latency, and when this happens, it never improves over time. The high latency persists until I redeploy. Even without making any code changes, I can trigger a redeploy and, if I’m lucky, I get a “good” server again and the latency issues disappear.
This pattern is very clear in my latest deployments, as shown in the attached image.
In the image, I attempted 2–3 redeploys. On the last one, I was lucky again and the errors disappeared.
This is happening on the Django production instance in the Diktatorial workspace.
Attachments
1 Replies
15 days ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 15 days ago
13 days ago
The graph actually looks like infrastructure-level latency rather than a Django problem.
Your baseline response time is extremely low (near 0–1 ms), but there are occasional spikes to ~25–30 seconds. If the application itself was slow, the baseline would also be higher.
Since the issue disappears after a redeploy with no code changes, the most likely explanation is that the container is sometimes scheduled on a host with heavy CPU contention or poor network routing.
This is often called the "noisy neighbor" problem on shared container platforms. If another tenant on the same node is consuming a lot of CPU or IO, your container can experience large latency spikes even though your own service is healthy.
You can confirm this by comparing:
- CPU throttling metrics between a "bad" and "good" deployment
- Django request processing time vs total request latency
- Database query timing
If redeploying consistently fixes it, it strongly suggests the container is being rescheduled onto a healthier host node.