A customer in Japan encountered an issue where web monitoring performed by HTTP pollers stopped working after upgrading Zabbix from version 5.0.30 to 7.0.19.

Timeline

1. Around June 19, 00:00
   Web monitoring stopped being executed. Web scenario data such as response codes was no longer updated.
2. Around June 30, 11:17
   The affected web scenario was disabled and re-enabled a few minutes later. The issue was resolved without any parameter changes.
3. Early morning on July 6
   The issue reoccurred. Disabling and re-enabling the web scenario did not resolve the problem. The issue was resolved after duplicating and recreating the web scenario.
4. Early morning on August 26
   The issue was resolved by restarting the Zabbix server service.

Possible Cause

We suspect that the following change may be related to this issue:

Related Issue

We believe this issue may be the same as, or closely related to, the following report:

https://support.zabbix.com/browse/ZBX-26346

Could you please investigate whether this issue is related to the removal of the `nextcheck` property introduced by ZBXNEXT-7921 and whether it matches the root cause of ZBX-26346?

Additional Observations

Based on the observed behavior, I suspect that the issue may involve the Configuration Cache or Configuration Syncer processes rather than being limited to the HTTP poller itself.

The reasons are as follows:

• The issue was resolved after restarting the Zabbix server.
• Disabling and re-enabling the affected web scenario temporarily resolved the issue, but the problem reoccurred later.
• Increasing the DebugLevel of the HTTP poller process through runtime control did not resolve the issue.My understanding is that this operation effectively refreshes process-specific state, so if the problem were caused solely by the HTTP poller process, I would have expected some change in behavior.
• I reviewed the HTTP poller debug logs during the affected period and found no obvious errors directly related to HTTP request processing.
• During the affected period, HTTP poller logs contained database-related "Query failed" messages. In three out of four occurrences, a "[4031] The client was disconnected by the server because of inactivity." message was followed by a "[2006] Server has gone away." message approximately one second later. In the remaining occurrence, the "Server has gone away" message was logged approximately four days after the corresponding "The client was disconnected" message.
  Simplified Logs

  20260619:000009.110 [4031] The client was disconnected by the server because of inactivity.
  20260619:000010.110 [2006] Server has gone away.
  20260620:030010.209 [4031] The client was disconnected by the server because of inactivity.
  20260620:030011.209 [2006] Server has gone away.
  20260623:060011.062 [4031] The client was disconnected by the server because of inactivity.
  20260623:060012.062 [2006] Server has gone away.
  20260626:050012.703 [4031] The client was disconnected by the server because of inactivity.
  20260630:105115.163 [2006] Server has gone away.
  

• The affected web scenario was configured with a 1-hour update interval, while the timing of the database-related log messages appeared irregular and did not follow a 1-hour pattern.

Taken together, these observations suggest that the issue may involve stale or inconsistent configuration data, or a problem in the configuration synchronization path, rather than being confined to the HTTP poller process itself.

Therefore, in addition to examining the HTTP poller, it may be worthwhile to investigate the behavior of the Configuration Cache and Configuration Syncer processes, as well as any related debug logs.