2 months ago
Subject: West4 Region - Production App Unusable
---
To: Railway Support Team
From: NovaDub Team
Date: December 7, 2025
Urgency: HIGH - Production Application Affected
---
## Issue Summary
Our production web application hosted on Railway is experiencing critically low download speeds for static assets, making the application effectively unusable. Users are waiting 2+ minutes to load the homepage.
## Environment Details
- Project ID: 6df3a8e7-1ef0-454a-9118-e3d06ebd1c09
- Service ID: 89bacfcf-8d2f-4960-9c7c-68a361988bf3
- Region: europe-west4-drams3a
- Domain:www.novadub.ai
- Railway URL:novadub-site-production.up.railway.app
## Problem Description
Static file downloads are extremely slow, with effective bandwidth of only ~90 Kbps (11 KB/s). This is approximately:
- 100x slower than typical cloud hosting
- 15x slower than Vercel
- 5.7x slower than Railway's own documentation site
## Diagnostic Data
### Test 1: Sequential Downloads (Same File, 650 KB gzipped)
```
Request 1: 75s @ 8.7 KB/s
Request 2: 107s @ 6.0 KB/s
Request 3: 120s @ 3.8 KB/s (TIMEOUT)
Request 4: 80s @ 8.1 KB/s
Request 5: 37s @ 17.7 KB/s
```
Observation: Extreme variability (4.6x difference), inconsistent performance.
### Test 2: Detailed Timing Breakdown
```
DNS Lookup: 0.002s (normal)
TCP Connect: 0.087s (normal)
TLS Handshake: 0.572s (normal)
First Byte: 0.771s (acceptable)
Total Time: 45.43s (CRITICAL)
Download Size: 649,762 bytes
Speed: 14,301 bytes/sec
```
Observation: Connection establishment is fast, but data transfer is severely throttled.
### Test 3: Parallel Downloads (3 simultaneous connections)
```
Total data: 1.95 MB (3 x 650 KB)
Total time: 99 seconds
Throughput: ~20 KB/s total (shared bandwidth)
Per connection: ~6.5 KB/s
```
Observation: Bandwidth is shared across connections, suggesting a total egress limit.
### Test 4: Comparison with Other Providers
| Provider | Speed | File Size |
|----------|-------|-----------|
| Vercel | 164 KB/s | 52 KB |
| GitHub CDN | 82 KB/s | 26 KB |
| Railway Docs | 63 KB/s | 29 KB |
| My Railway App | 11 KB/s | 650 KB |
### Test 5: TTFB Variability
```
Test 1: TTFB = 0.35s
Test 2: TTFB = 2.57s
Test 3: TTFB = 1.49s
```
Observation: Time To First Byte varies by 7x, indicating server-side instability.
## Questions
1. Is there a bandwidth throttling policy on the europe-west4 region?
2. Are there any known issues with the europe-west4-drams3a edge server?
3. Is there a way to increase our egress bandwidth allocation?
4. Would migrating to a different region improve performance?
5. Are there any recommended configurations for serving static files?
## Business Impact
- User Experience: Homepage takes 2+ minutes to load (unacceptable for a SaaS product)
- Bounce Rate: Users leave before the page loads
- SEO Impact: Core Web Vitals are severely affected
- Revenue Impact: Potential customers cannot access our service
## Requested Actions
Investigate why our specific deployment has such low bandwidth
## Additional Information
We are happy to provide:
- Access to our Railway project for investigation
- Additional diagnostic logs
- Any other information needed
Thank you for your urgent attention to this matter.
---
Project: NovaDub (www.novadub.ai)
9 Replies
2 months ago
I can confirm this issue on europe-west4-drams3a. Public network speed is unbearably slow at the moment. Please prioritize this issue as it affects apps in production.
2 months ago
Hi! Are you able to run https://docs.railway.com/reference/network-diagnostics and share the output here?
Status changed to Awaiting User Response Railway • 2 months ago
Status changed to Awaiting Railway Response Railway • 2 months ago
raphaelflash
Here you go
2 months ago
Are you able to open your own thread mentioning this? Apologies for the trouble; it'll help us track these issues easier.
Status changed to Awaiting User Response Railway • 2 months ago
2 months ago
@dicemans are you able to share an example link to a static file that is slow? I'm unable to reproduce the issue on your site from my end. Additionally, running https://docs.railway.com/reference/network-diagnostics and sharing the output here would help us troubleshoot this with more information. Thank you!
Status changed to Solved dicemans • 2 months ago
2 months ago
Hi, thanks for your response. Here is the information you requested ( attached file ):
Link for test
As also mentioned by raphaelflash, the issue is intermittent and occurs frequently during evening hours (timezone: Europe/Rome – CET/CEST).
I have also noticed through additional testing that it tends to happen right after a machine re-deploy and continues for approximately 15–30 minutes after the deployment completes.
I’m available to provide any further details if needed.
Thanks.
Attachments
Status changed to Awaiting Railway Response Railway • 2 months ago
2 months ago
The link 404s for me.
Given your output, I can see that:
You're connecting from Rome using Starlink
You're being routed to our EU edge, which is correct
Your traceroute shows the optimal path (Budapest->Prague->Amsterdam->Railway's Datacentre)
Any latency you're experiencing may be coming from your connection, or your application itself. Starlink is prone to packet losses from what I understand - could that be causing issues?
Status changed to Awaiting User Response Railway • 2 months ago
2 months ago
Thank you for your response. However, I have evidence that disproves the Starlink/network theory.
---
### Test: Same Network, Different Providers
From the SAME machine with SAME network (Starlink):
```bash
# Railway (our app)
curl -w "Speed: %{speed_download} bytes/sec\n" -o /dev/null -s \
"https://novadub-site-production.up.railway.app/assets/index-Cie3DRno.js"
# Result: 23,203 bytes/sec (98 seconds for 2.2MB)
# Cloudflare CDN
curl -w "Speed: %{speed_download} bytes/sec\n" -o /dev/null -s \
"https://cdnjs.cloudflare.com/ajax/libs/three.js/r128/three.min.js"
# Result: 2,463,935 bytes/sec (0.24 seconds for 600KB)
```
| Provider | Speed | Comparison |
|----------|-------|------------|
| Railway | 23 KB/s | 1x |
| Cloudflare | 2,463 KB/s | 106x faster |
If it were Starlink latency, Cloudflare would also be slow. It's not.
---
### Test Files for Your Verification
I've created static test files you can download:
1MB Test File:
```bash
curl -w "Speed: %{speed_download} bytes/sec, Time: %{time_total}s\n" \
-o /dev/null -s \
"https://novadub-site-production.up.railway.app/bandwidth-test-1mb.bin"
```
Expected result: ~23 KB/s = ~45 seconds for 1MB
Instructions file:
https://novadub-site-production.up.railway.app/railway-test.txt
---
### Key Evidence
1. Same client downloads from Cloudflare at 2.4 MB/s → Network is fine
2. Railway downloads at 23 KB/s → 100x slower than expected
3. First byte is fast (330ms) → Connection is established quickly
4. Transfer is slow → Egress bandwidth is throttled
---
Status changed to Awaiting Railway Response Railway • 2 months ago
2 months ago
Hi there,
I'm unable to reproduce this with the links you provided.
Using your own test files and commands, here are the results I'm seeing from a central European consumer internet line:
1mb bin file: Speed: 2635540 bytes/sec, Time: 0.397860s
JS file: Speed: 6569275 bytes/sec, Time: 0.346704s
Best,
Nico
Status changed to Awaiting User Response Railway • 2 months ago
2 months ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • about 2 months ago