Hi — a few observations from the numbers you posted, plus a short list of checks that should narrow this down quickly without needing a platform-side investigation first.

1. What the counters actually say. Per the MySQL reference manual (Communication Errors and Aborted Connections), Aborted_connects increments when a client fails to complete the connection (bad credentials, no privilege on the DB, malformed connect packet, or taking longer than connect_timeout to send the handshake packet), while Aborted_clients increments when a client connected fine but disconnected improperly (process exited without mysql_close(), sat idle past wait_timeout, or dropped mid-transfer). Your Threads_connected: 2 and Max_used_connections: 11 against Max_connections: 151 confirm you're nowhere near the connection limit — so this isn't MySQL refusing connections for capacity reasons. It points at the connect phase, or at connections being dropped between requests.

2. Which host are you connecting to? This is the single most important question. If your PHP service uses the public TCP proxy (xxxx.proxy.rlwy.net:NNNNN / MYSQL_PUBLIC_URL), every request leaves the private network, goes through the proxy and comes back, and bursts of parallel connects are much more exposed to resets/timeouts than on the internal network. Switch to the private hostname (mysql.railway.internal:3306, i.e. the MYSQL_URL / MYSQLHOST reference variables) — it stays inside the project's network (Wireguard-encrypted per the docs). One caveat: Railway's private network is IPv6, so connect by hostname (not an IPv4 literal) and make sure the mysqlnd driver is in use — it handles IPv6 fine.

3. Get the actual MySQL error code into your logs. "500" hides the discriminating detail. Send PHP errors to stderr (log_errors=On, error_log=/dev/stderr) and log mysqli_connect_errno() / mysqli_connect_error() (or the PDOException code) on failure. The code tells you which family you're in:

• 2002 / 2003 (can't connect, refused, timed out) → network / connect phase
• • 2006 (server has gone away) / 2013 (lost connection during query) → a connection opened earlier was killed, typically wait_timeout hitting a persistent connection
• • 1040 (too many connections) → capacity (unlikely given your numbers)
• • 1045 / 1044 → credentials / privileges — would also explain Aborteda_connects if one API uses a different or legacy credential set

4. Persistent connections + wait_timeout is a classic cause of exactly this pattern. If you use p:-prefixed hosts in mysqli or PDO::ATTR_PERSISTENT, PHP-FPM workers keep sockets open between requests; when MySQL closes them after wait_timeout, the next request on that worker fails (one Aborted_clients increment and one 500) while a neighbouring worker with a fresh socket returns 200 — i.e. "some requests fail, others succeed at the same instant", and "works on some systems, not others" because it depends on which worker your browser's parallel calls land on. Quick test: disable persistent connections (or add a mysqli_ping / SELECT 1 guard before reuse) and see if the 500s stop under the same dashboard load.

5. Run these on the MySQL service and share the output if the above doesn't settle it:

SHOW GLOBAL STATUS LIKE 'Connection_errors%';
SHOW GLOBAL VARIABLES LIKE 'wait_timeout';
SHOW GLOBAL VARIABLES LIKE 'max_connect_errors';
SELECT * FROM performance_schema.host_cache;

Connection_errors_* breaks the failures down (peer_address, tcpwrap, internal, max_connections), and host_cache shows per-client-host error counters — if max_connect_errors is ever reached for your PHP service's host, MySQL blocks that host entirely until FLUSH HOSTS, which would look like a sudden wall of 500s.

6. Also worth checking on the PHP side: PHP-FPM pm.max_children (or Apache MaxRequestWorkers) vs how many parallel calls the dashboard fires. Queued requests would show up as latency rather than 500s, so this is lower priority — but a worker hitting memory_limit or max_execution_time under parallel load is another way to get sporadic 500s that have nothing to do with MySQL.

#2 and #3 — 5-minute changes that will tell you whether this is a connect-path issue or a stale-connection issue, which are fixed very differently. Happy to dig

further once you have the error codes.