Skip to main content
A
AK_127457874-Participant
4-Participant
July 28, 2026
Solved

Intermittent OPC UA Publish BadTimeout Errors from Kepware Causing Data Gaps in Azure IoT Operations OPC UA Connector

  • July 28, 2026
  • 1 reply
  • 16 views

We are using 3 Kepware (KEPServerEX) servers connected to Azure IoT Operations (AIO) OPC UA Connector, which forwards data to Azure IoT Hub.

Recently, we observed intermittent missing payloads/data gaps of approximately 4 minutes across all three Kepware servers simultaneously. During these periods, no telemetry was received in Azure.

We raised a support case with Microsoft, and after analyzing the OPC UA Connector logs, they provided the following finding:

Analysis of the OPC UA Connector logs shows that the payload gaps coincide with OPC UA BadTimeout publishing errors, i.e. periods where the OPC UA servers did not return a response to the connector's Publish requests within the operation timeout. During each of these periods no data-change or keep-alive notification is delivered, and therefore the per-minute keyframe for that period is not produced. This is the primary cause of the reported payload shortfall.

We are trying to understand the issue from the Kepware/OPC UA Server side and would appreciate any guidance.

Environment

  • 3 x KEPServerEX instances in independent Virtual machines
  • Azure IoT Operations OPC UA Connector as OPC UA client
  • Azure IoT Hub as destination
  • Data gaps observed for ~4 minutes
  • All three servers affected during the same timeframe

Questions

  1. Under what conditions can KEPServerEX return or contribute to OPC UA BadTimeout Publish errors?
  2. Are there known scenarios where the server stops responding to Publish requests temporarily while remaining otherwise operational?
  3. Which Kepware logs, diagnostics, or performance counters should we review to identify the root cause?
  4. Could this be related to:
    • High CPU or memory utilization?
    • Large number of monitored items/subscriptions?
    • Network latency or packet loss?
    • OPC UA session/subscription limits?
    • Publishing interval or keep-alive configuration?
  5. Has anyone experienced similar intermittent Publish timeout issues with Kepware acting as the OPC UA server?

Any recommendations on troubleshooting steps, logging settings, or best practices would be greatly appreciated.

Thanks in advance for your help.

Additional Information: The issue affected all three Kepware servers at nearly the same time, so we're also investigating whether there could be a common infrastructure, network, or client-side factor involved. However, we'd like to understand what Kepware-side conditions might lead to OPC UA Publish request timeouts seen by the OPC UA client.

Thanks!

Best answer by MRohilla

Greetings ​@AK_12745787 ,

 

The key observation is that all 3 independent Kepware servers experienced the issue at nearly the same time, which makes a common infrastructure, network, or client-side issue more likely than three separate Kepware server failures.

 

Kepware-side conditions that can contribute to OPC UA BadTimeout Publish errors

High CPU, memory pressure, or VM scheduling delays.

Excessive subscriptions/monitored items causing Publish processing delays.

Burst data changes overwhelming subscription processing.

Slow or blocked communication with underlying PLCs/devices.

Antivirus scans, backups, snapshots, or OS-level resource contention.

Can Kepware remain operational while Publish requests timeout?

 

Yes. OPC UA Publish requests are held until data changes or keep-alives are available. If the server is delayed in responding, the client may see BadTimeout even though the session remains connected and other operations continue to work.

 

What should be reviewed?

KEPServerEX Event Log for OPC UA/session/subscription warnings.

Windows Performance Metrics

CPU

Memory

Disk latency

Network utilization

OPC UA Diagnostics

Active sessions

Subscription count

Monitored item count

Wireshark traces to check:

Publish response delays

TCP retransmissions

Packet loss

Hypervisor/VM logs for snapshots, backups, or resource contention.

Most likely areas to investigate

 

Given that all three servers were affected simultaneously:

 

Shared network issue (latency, packet loss, firewall, SDN).

Azure IoT Operations OPC UA Connector resource bottleneck or node issue.

Virtualization platform event affecting multiple VMs.

Common infrastructure maintenance/backup activity.

Recommendation

 

Correlate timestamps across:

 

AIO OPC UA Connector logs

KEPServerEX logs

Windows Event Logs

Hypervisor/network logs

 

If possible, collect synchronized Wireshark captures on both the Kepware server and the AIO connector during the next occurrence to determine whether Publish responses were delayed by Kepware or lost/delayed in transit. This will quickly isolate whether the root cause is server-side or infrastructure/client-side.

Regards,

Mohit

1 reply

M
MRohillaCommunity ManagerAnswer
Support
August 3, 2026

Greetings ​@AK_12745787 ,

 

The key observation is that all 3 independent Kepware servers experienced the issue at nearly the same time, which makes a common infrastructure, network, or client-side issue more likely than three separate Kepware server failures.

 

Kepware-side conditions that can contribute to OPC UA BadTimeout Publish errors

High CPU, memory pressure, or VM scheduling delays.

Excessive subscriptions/monitored items causing Publish processing delays.

Burst data changes overwhelming subscription processing.

Slow or blocked communication with underlying PLCs/devices.

Antivirus scans, backups, snapshots, or OS-level resource contention.

Can Kepware remain operational while Publish requests timeout?

 

Yes. OPC UA Publish requests are held until data changes or keep-alives are available. If the server is delayed in responding, the client may see BadTimeout even though the session remains connected and other operations continue to work.

 

What should be reviewed?

KEPServerEX Event Log for OPC UA/session/subscription warnings.

Windows Performance Metrics

CPU

Memory

Disk latency

Network utilization

OPC UA Diagnostics

Active sessions

Subscription count

Monitored item count

Wireshark traces to check:

Publish response delays

TCP retransmissions

Packet loss

Hypervisor/VM logs for snapshots, backups, or resource contention.

Most likely areas to investigate

 

Given that all three servers were affected simultaneously:

 

Shared network issue (latency, packet loss, firewall, SDN).

Azure IoT Operations OPC UA Connector resource bottleneck or node issue.

Virtualization platform event affecting multiple VMs.

Common infrastructure maintenance/backup activity.

Recommendation

 

Correlate timestamps across:

 

AIO OPC UA Connector logs

KEPServerEX logs

Windows Event Logs

Hypervisor/network logs

 

If possible, collect synchronized Wireshark captures on both the Kepware server and the AIO connector during the next occurrence to determine whether Publish responses were delayed by Kepware or lost/delayed in transit. This will quickly isolate whether the root cause is server-side or infrastructure/client-side.

Regards,

Mohit

Terms & ConditionsAccessibility statement