max_connections_per_hour Error: Why Your Site Shows Database Error

A site that worked fine yesterday suddenly shows "Database Error" or "Error establishing a database connection", then recovers on its own an hour later, and the next day it happens again. A common cause of this on-and-off failure is an hourly connection limit set on the MySQL user. It appears in logs as max_connections_per_hour, and once you understand it you can diagnose it in minutes.

What error 1226 actually says

MySQL can assign per-user resource limits: how many queries, updates and new connections a user may make per hour. When the hourly connection count is exceeded, the server refuses new connections:

ERROR 1226 (42000): User 'shop_user' has exceeded the
'max_connections_per_hour' resource (current value: 50)

The limit counts every connection opened during the hour, not concurrent ones. On PHP sites each page view usually opens a new connection, so with a limit of 50 the site stops after roughly 50 page views per hour. The counter resets when the hour ends, which is why the error seems to fix itself and then returns with traffic.

Telling it apart from similar errors

1226 means the hourly quota is used up. 1203 (max_user_connections) means too many simultaneous connections for that user. 1040 Too many connections means the whole server's limit is full, usually unrelated to one account. 1045 Access denied is a wrong user name or password. Visitors only see a generic database error page, so look for the exact code in the PHP error log or the error_log file in the site folder.

Checking and raising the limit

With admin access to MySQL, for example on your own VPS, check the user's limits. The max_connections column holds the hourly limit; 0 means unlimited:

SELECT user, host, max_questions, max_updates,
       max_connections, max_user_connections
FROM mysql.user
WHERE user = 'shop_user';

Raise it with ALTER USER and reset the counters immediately with FLUSH USER_RESOURCES; otherwise you wait for the hour to end:

ALTER USER 'shop_user'@'localhost'
  WITH MAX_CONNECTIONS_PER_HOUR 20000;
FLUSH USER_RESOURCES;

On shared hosting, regular users cannot access this table, so ask support. Limits there also protect the server from one account taking all resources, so a generous value that fits real traffic is usually chosen instead of unlimited.

Reducing the number of connections

Enable page caching: a cached page does not touch the database at all.
Look for crawlers hammering the same pages in the access log and restrict them at site level.
Make sure cron jobs are not running every minute when every five or fifteen minutes would do.
On WordPress, admin-ajax.php requests keep firing even from a forgotten open admin tab.

Example: a clinic site failing at lunchtime

A private clinic in Samarkand, example.uz, went down for about an hour every day around noon, exactly when the appointment schedule and booking form were busiest. The PHP error log showed a run of 1226 entries, and the access log showed several hundred page views per hour, far above the limit of 50. Support raised the limit and flushed the counters, while the owner enabled page caching and moved the schedule update job from every minute to every ten minutes. The error disappeared and pages became faster. On sayt.uz hosting, opening a ticket in the cabinet with the error code is enough.

Keeping it from coming back

This limit usually surfaces for the first time when a site grows. Before an ad campaign or seasonal sale, confirm the database limits can handle the expected load, review the error log weekly, verify caching works and keep unnecessary bots in check. A few minutes of routine checks are far cheaper than an hour of downtime during your busiest period.