ERROR: SQLSTATE[HY000] [2002] No connection could be made because the target machine actively refused it.

Question

ERROR: SQLSTATE[HY000] [2002] No connection could be made because the target machine actively refused it.

Nischay 125

Hello,

We have a dashboard running on Azure App Service, connected to an Azure MySQL database. Earlier today, we experienced a connection issue that was resolved after restarting the server. Below are the relevant PHP (Laravel) logs:

2026-03-26 22:27:26] production.ERROR: SQLSTATE[HY000] [2002] No connection could be made because the target machine actively refused it. {"exception":"[object] (PDOException(code: 2002): SQLSTATE[HY000] [2002] No connection could be made because the target machine actively refused it. at C:\\home\\site\\wwwroot\\vendor\\laravel\\framework\\src\\Illuminate\\Database\\Connectors\\Connector.php:70) [stacktrace] [2026-03-26 22:27:29] production.ERROR: SQLSTATE[HY000] [2002] No connection could be made because the target machine actively refused it. (SQL: select * from `classes` where `join_code` = ios_first_run) {"exception":"[object] (Illuminate\\Database\\QueryException(code: 2002):

We also observed a CPU spike on the SQL database around the same time (screenshot attached).

Any suggestions or advise on what might have caused this issue, and any steps we can take to prevent it in the future?

SAI JAGADEESH KUDIPUDI 3,645 Reputation points Microsoft External Staff Moderator

2026-03-27T01:56:08.0333333+00:00

Hi Nischay,
Could you please share the requested details in a private message
Santhosh Kumar Machukuri 0 Reputation points Microsoft External Staff Moderator

2026-04-01T17:55:02.2766667+00:00

Hi Nischay,

Can you please share exact timestamps of the issue with time zone, thanks in advance.
Nischay 125 Reputation points

2026-04-01T22:16:02.9133333+00:00

Hi Santhosh,
The issue occurred on 26th March 2026 at 10:27 PM (UTC), which matches the timestamps in the error logs we shared earlier. The CPU spike graph included in our question reflects the same incident at the same time - it shows 27th March 2026 at 11:27 AM (NZDT), as NZDT is 13 hours ahead of UTC.
Santhosh Kumar Machukuri 0 Reputation points Microsoft External Staff Moderator

2026-04-01T22:27:39.7466667+00:00

Hi Nischay,

Thanks for sharing, we will check the data and get back to you.
Nischay 125 Reputation points

2026-04-14T22:27:27.9533333+00:00

Hi @Santhosh Kumar Machukuri and @SAI JAGADEESH KUDIPUDI ,

Just checking if you got a chance to review the data and can help us with this issue :)

Best Regards,
Nischay

1 answer

Your answer

SAI JAGADEESH KUDIPUDI 3,645 Reputation points Microsoft External Staff Moderator

2026-03-27T01:56:08.0333333+00:00

Hi Nischay,
Could you please share the requested details in a private message
Santhosh Kumar Machukuri 0 Reputation points Microsoft External Staff Moderator

2026-04-01T17:55:02.2766667+00:00

Hi Nischay,

Can you please share exact timestamps of the issue with time zone, thanks in advance.
Nischay 125 Reputation points

2026-04-01T22:16:02.9133333+00:00

Hi Santhosh,
The issue occurred on 26th March 2026 at 10:27 PM (UTC), which matches the timestamps in the error logs we shared earlier. The CPU spike graph included in our question reflects the same incident at the same time - it shows 27th March 2026 at 11:27 AM (NZDT), as NZDT is 13 hours ahead of UTC.
Santhosh Kumar Machukuri 0 Reputation points Microsoft External Staff Moderator

2026-04-01T22:27:39.7466667+00:00

Hi Nischay,

Thanks for sharing, we will check the data and get back to you.
Nischay 125 Reputation points

2026-04-14T22:27:27.9533333+00:00

Hi @Santhosh Kumar Machukuri and @SAI JAGADEESH KUDIPUDI ,

Just checking if you got a chance to review the data and can help us with this issue :)

Best Regards,
Nischay

Answer 1

The PDO 2002 message confirms the App Service could not open a TCP connection to MySQL, but it does not prove the cause. Because the failure coincided with a CPU spike and cleared after restart, resource saturation, connection exhaustion, or a transient restart/failover are the leading possibilities.

In Azure Monitor, correlate 22:27 UTC with Host CPU, Memory, Storage IO, Active Connections, Total Connections, and Aborted Connections. Check Resource Health and the Activity Log for maintenance or failover. Enable MySQL error and slow-query logs, then inspect statements running immediately before the spike. Verify the application uses the server FQDN, connection pooling, finite timeouts, and retry logic with exponential backoff. Optimize slow queries and scale compute if CPU remains sustained. If this recurs without a matching metric or log event, open Microsoft Support with the UTC timestamp, server name, and relevant logs.