Representing a network delay in fetching the status of a network object

Question

Back story

I am working on a monitoring view of a network management system. The system allows the user to deploy a network object in a client environment. Once done, this monitoring view shows the current state of the objects starting from "creating" network resources for that object deployment.

The different states we have are: Creating, Created, Deploying, Running, Sub-optimal, Error, Deleting and Deleted

The monitoring view consumes data from two different systems(using individual APIs) switching from one system to another based on the current state of the network object.

Let's say system A(sA) gives states Creating, Created, Deploying, Deleting and Deleted. and system B(sB) gives Running, Sub-optimal and Error.

A few of these are stable states and a few are transient states between stable states. The above states are represented clearly with color codes, labels, and timestamps.

The issue:

When the UI moves from consuming states from sA to sB, there may be a delay in connecting to sB. In this gap what is the best way to show the transience.

We can not show the state Deploying as the network object can also fail deployment and had gone to Error state. But this state is given only by sB.

The Question:

Is it okay/correct, to include states for such delays such as "Fetching status.." or "loading status.." or something similar while the UI is moving from sA to sB? [note that we do not need or want the user to know that there are two separate systems where the status are being consumed from.]

or

just leave it as it is?

// Update //

This is what we have right now, all the available status(in the order of their occurrence) and how they are represented. Now I need to introduce a state(or do i even need to ?) which is shown when there is a lag between changing, fetching the next status (PS: from another system or even the same system)

Answer 1

I'm assuming that when the system is first loaded, the status is instantly shown?

If not, do you have a way to show that the status is being fetched when the person first sees the screen where the status is shown?

I would recommend something as simple as a spinner, to show the user that something is being done to change the status.

This depends on how long it takes to change the status, though. If there's a 0.2 second delay between showing a status from "sA" and showing one from "sB", there's probably not much need for one.

But if the delay is 5 seconds, for example, showing something as simple as a spinner reassures the person that something is happening and that they should wait.

Answer 2

When the status of an entity progresses from Created to the end of life cycle, its very important to display the actual status.

"Fetching Status" | "Loading Status"

Having a buffer status will prevent unintended actions/decisions on entities by users based on Statuses.