Monitor virtual cluster status
The Gateway Manager cluster table and virtual cluster detail view show the real-time state of a virtual cluster. Use these views to understand whether the cluster is operating normally, in a degraded or failover state, or fully offline.
Cluster table
Virtual clusters appear in the cluster table alongside physical clusters with a VIRTUAL type badge. The Status and Connection columns use the same states for virtual and physical clusters.
The Connection column shows a three-state indicator with a reachable-member count:
The Status column shows Enabled or Disabled and is consistent with physical cluster behavior.
Virtual cluster detail view
Select a virtual cluster in the cluster table to open its detail view. The detail view includes the following tabs.
Failover Chain tab
The Failover Chain tab shows all member clusters, their current connection state, and any service parity warnings. It is present on both active/standby and load-balanced virtual clusters, and is where the Distribution type can be changed via Edit Cluster.
For active/standby clusters, the preview section is labeled Failover Chain (Preview) and shows members in priority order—primary first, then backups in sequence—with the note “Failover executes top to bottom. Highest ranking connected cluster will receive requests.” Each member entry displays:
- Enabled/Disabled and Primary/Backup badges
- The cluster ID and description
- Last connected timestamp
- Connection status indicator
- A warning indicator if the backup cluster is missing any services present on the primary
For load-balanced clusters, the preview section is labeled Cluster Pool (Preview) with the note “Work is distributed across all connected clusters based on current load.” Members are still shown with Primary and Backup badges reflecting configuration order, but all reachable members actively serve traffic regardless of badge.
Service Groups tab
The Service Groups tab displays service groups configured on the virtual cluster, similar to physical clusters. Service groups on a virtual cluster allow you to control access to specific service subsets across member clusters. To add or modify service groups on individual member clusters, navigate to that physical cluster’s detail view.
Services tab
The Services tab displays services registered on the primary cluster. It is read-only — to sync services across all member clusters, import a configuration on the virtual cluster. Importing at the virtual cluster level propagates the configuration to all connected members in one action. Importing directly on an individual member cluster only affects that member and can create a mismatch with the primary. For procedures, see Import a gateway configuration.
Service matching uses name and type as the comparison key. This is a presence check only—it doesn’t verify that services with matching names execute equivalent code. Service parity warnings appear on the Failover Chain tab, not here. Confirm that services are functionally equivalent across all members before routing production traffic through the virtual cluster.
Workflows tab
The Workflows tab displays workflows associated with the virtual cluster. For details on managing workflows, see Workflows.
How load balancing distributes jobs
For reference when interpreting member load in a load-balanced virtual cluster:
- Each new job is dispatched to the reachable member with the fewest currently active jobs (least outstanding requests).
- Position in the backup list breaks ties between equally-loaded members.
- Once dispatched, a job is never split across members or reassigned mid-execution.
- A Platform workflow that makes multiple separate service calls distributes each call independently. A single workflow can legitimately run different calls on different members; each individual call still completes on the one member it was dispatched to.
Virtual clusters route new jobs away from an unreachable member automatically. If a member becomes unreachable while a job is running on it, that job doesn’t transfer to another member and must be resubmitted manually. Neither distribution type guarantees in-flight job recovery.