a month ago
Hello Railway Support Team,
I am experiencing unexpected shutdowns of my MySQL service deployed on Railway. The database starts successfully, initializes InnoDB properly, and becomes ready for connections, but within a short time it receives a shutdown signal and stops gracefully.
Below are the relevant logs:
Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/062910d4-b763-4de1-922e-497a61820006/vol_m547k61kvpqfon3x
Starting Container
2026-02-11T14:38:28.553773Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2026-02-11 14:38:27+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 9.6.0-1.el9 started.
2026-02-11 14:38:27+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
'/var/lib/mysql/mysql.sock' -> '/var/run/mysqld/mysqld.sock'
2026-02-11T14:38:28.419097Z 0 [System] [MY-015015] [Server] MySQL Server - start.
2026-02-11T14:38:28.542274Z 0 [System] [MY-010116] [Server] mysqld 9.6.0 starting as process 1
2026-02-11T14:38:32.622841Z 0 [System] [MY-010931] [Server] ready for connections.
However, shortly after startup:
2026-02-11T14:40:03.918908Z 0 [System] [MY-013172] [Server] Received SHUTDOWN from user . Shutting down mysqld (Version: 9.6.0).
2026-02-11T14:40:07.460486Z 0 [System] [MY-015016] [Server] MySQL Server - end.
The shutdown appears to be triggered by a user signal (SIGTERM), but I am not manually stopping or redeploying the service at that time.
Could you please help clarify:
What might be triggering this shutdown signal?
Whether this could be related to container health checks, memory limits, auto-scaling, or platform-level restarts?
If there are any logs or metrics I should review to diagnose this further?
The database starts normally and shows no corruption or fatal errors, so it appears to be externally triggered.
Looking forward to your guidance.
Best regards,
Ritik Raj
2 Replies
a month ago
Hey there!
It looks like this was a part of a recent incident we have. I just checked and it should be good to go now. Can you give it a look and let me know what you're seeing?
Post mortem is here in case you're interested in reading it.
https://blog.railway.com/p/incident-report-february-11-2026
Status changed to Awaiting User Response Railway • 27 days ago
a month ago
I know Noah replied here but want to get others who may see a full rundown. (Esp for Ritik)
First, apologies for the delayed response here, and I want to acknowledge that others reading this thread may be experiencing similar behavior. This applies to you too.
To answer your questions directly: this was us, not your service. Your MySQL instance was healthy. It initialized correctly, InnoDB was fine, and there was no corruption or misconfiguration on your end.
Here's what happened: Railway runs automated systems to detect and shut down abusive/fraudulent workloads on our platform. On February 11th, we rolled out an update to those detection rules that contained a logic bug, causing it to false-positive on legitimate services - yours and others included. The SIGTERM your MySQL process received at 14:40:03Z was sent by our platform, not by any health check, memory limit, or auto-scaling behavior. This is also why it looked so confusing from your side. That's entirely on us.
The rule change has been rolled back. Your MySQL service should now stay up without unexpected shutdown signals. If you or anyone else reading this is still seeing unexpected restarts or any data integrity issues, please open a ticket and we will escalate immediately.
Full incident report: https://blog.railway.com/p/incident-report-february-11-2026
We're putting safeguards in place so that automated actions like this require human review before they can affect established services. That should have already been the case.
Apologies again for both the disruption and the slow acknowledgment.
20 days 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 • 20 days ago