We experienced a major service disruption starting at 02:25 UTC on May 20 that affected the entire platform, which was resolved by 07:57 UTC. A separate build performance issue is currently being monitored after a fix was deployed. All of your services are currently showing successful deployments. We hear your feedback on communication during incidents, and a post-mortem has been published with full details on what happened and what we are doing to prevent recurrence.

No, I’m experiencing a connection issue with the MySQL database. Some services are not functioning properly.

The application is unable to communicate with MySQL, which is causing operational issues.

I’m currently experiencing problems on the following platforms:

bfcc0e9a-3f0b-449c-a2a0-a7d67e65b1e0

a72f7907-c3d8-45ea-8814-da1f543005f6

MySQL shows SUCCESS, but in practice it is inaccessible, even from within Railway itself. I’m going to force a restart of it.

????????????????????????????????????????????????????????????????????????????????????????????????????????????????

?????????????????????????????????????????????????????????????????????????????????????????????????????w

Railway — Production Outage Report (URGENT)

Project: apiforge — a72f7907-c3d8-45ea-8814-da1f543005f6

Account: maicouandrade@msconsultoria.net.br (Pro plan)

Date: May 20, 2026

Impact: Production API down. My customer cannot access data right now.

I need someone from your team to look at this today. Multiple Railway-side problems are blocking my production system. None of these are caused by my code — they are platform issues.

1. MySQL data loss — apiforge.queries table is gone

Service: MySQL 5cd57c58-bb57-424c-910b-0a73e16682e4

The queries table existed and was serving 5,000+ rows at 13:30 BRT today. After a MySQL hiccup (see #2), every query now returns:

Table 'apiforge.queries' doesn't exist

I did not drop the table. No migrator ran today. Please check the persistent volume for this MySQL instance — did it detach, reset, or get replaced? If the data is gone, I need to know now so I can rebuild from schema.

2. MySQL was unreachable on internal network

At ~14:08 BRT, queries from the painel service (9845a292-f5b0-417e-a4b4-532f24796f3f) to mysql.railway.internal:3306 returned connect ETIMEDOUT after 11.5 seconds.

The MySQL deployment was reporting SUCCESS the whole time. Deployment status does not reflect actual database health. This is misleading.

A manual serviceInstanceRedeploy on the MySQL service recovered it after ~90 seconds.

3. TCP proxy dropping external MySQL connections

External clients connecting to shuttle.proxy.rlwy.net:55153 complete the TCP handshake but get the connection closed immediately during the MySQL protocol handshake. Driver error (mysql2):

Connection lost: The server closed the connection.

This caused my external Node.js service (running on a Windows VM behind a Cloudflare Tunnel) to crash repeatedly on startup until the wrapper gave up after 3 retries. Service has been down since.

Is there a rate limit, IP throttle, or active incident on the TCP proxy in the gru region today?

4. Build queue stalled

Deployments stuck in QUEUED for 10+ minutes (normal for this Next.js project: 2-3 minutes total). Example: deployment created 14:45:20 UTC was still QUEUED 10+ minutes later. Multiple deploys today affected.

What I need

1. Check the volume of MySQL service 5cd57c58-bb57-424c-910b-0a73e16682e4 — is data intact? Was it replaced/detached today?
2. Status of TCP proxy shuttle.proxy.rlwy.net:55153 — incident, throttle, or normal?
3. Status of build queue in gru today — degraded?
4. Confirm if there is an active incident affecting MySQL or proxies in South America today. If yes, please share the status page.

I will not be rotating my code or infrastructure further until I get clarity on these four points — I need to know what is on my side versus yours.

Have you tried redeploying your MySQL service? (Not restart)

This sounds even worse because of deploy issues. In my opinion not porfect idea