This is a Cube client timeout, which is totally normal given the fact that by default Cube tries to use a communication method called eventing. This method can require some setup to work properly, so when it fails, Cube falls back to another method called polling.
.NET Remoting with or without eventing (see DataMiner Help)
By default, clients connecting to a DataMiner Agent use .NET Remoting with eventing.

• .NET Remoting with eventing: When a client uses .NET Remoting with eventing, the DataMiner Agent will send server-initiated notifications to the client. So when a client application such as DataMiner Cube connects to a DataMiner Agent, it will open a random port on the client to which the DMA will send its notifications.
• .NET Remoting without eventing: When a client uses .NET Remoting without eventing, the DataMiner Agent will not send server-initiated notifications to the client. Instead, the client application will continuously poll the DataMiner Agent for notifications.

When a fallback from polling to eventing occurs, an information event is generated that contains the IP address and port that the events are sent to. Clients can use this information to detect why they cannot receive events via the callback method. When a client connects, the log files and diagnostic info also contain the external client IP address as seen from the DataMiner Agent.

The easiest way to avoid the notification is to configure the client to default to polling. Keep in mind that this is a computer setting, so it will have to be applied on every computer accessing Cube.

Alternatively, you can configure the entire DMA to always use polling, by adapting the configuration in the file ConnectionSettings.txt.
The default setting to use eventing looks like this in this file:

• type=RemotingConnection;polling=0;zip=true

To instead use polling (1000 ms) by default, change this as follows:

• type=RemotingConnection;polling=1000;zip=true