Ops & Clusters
Ops is where apps actually get onto edge clusters, and where you watch whether they landed. When you deploy something from the App Store, Ops is the machinery underneath, and this view is how you see what it did.
It is available to platform staff and tenant administrators. Engineers get a read-only view; Operators do not see it.
Two deployment modes
How a deployment reaches a cluster depends on how that tenant is set up.
| Mode | Used for | How it works |
|---|---|---|
| Internal | Tenants running on platform-managed infrastructure | The app is installed directly onto the local cluster |
| External | Tenants running their own cluster | The deployment is packaged as a bundle and picked up by an agent running on the customer's cluster |
You do not choose the mode per deployment. It follows the tenant's configuration, and the console routes automatically. The practical difference is visibility: external deployments go through a sync step, so they surface a Pending state that internal deployments skip.
Reading the summary
The Ops summary is a row of counters covering everything you have visibility into:
| Counter | What it means |
|---|---|
| Clusters Ready | Downstream clusters healthy and checked in |
| Clusters Pending | Registered, but no agent check-in yet |
| Clusters Error | Registered and failing to connect |
| Bundles Deployed | Deployment units successfully applied to their targets |
| Bundles Pending | Units waiting to be applied |
| Repos Active | Configuration sources with all targets in sync |
| Repos Error | Configuration sources failing to sync |
A healthy fleet sits at zero in every Error and Pending column. Pending that never clears is the signal worth chasing, because it usually means an agent cannot reach the platform rather than that a deployment is wrong.
Cluster status
The cluster list shows every downstream cluster, with:
| Field | Description |
|---|---|
| Name | Cluster identifier, DNS-compatible |
| Display Name | The human-readable label |
| Status | Ready, Active, NotReady, or WaitCheckIn |
| Node Count | Nodes in the cluster |
| Bundle Count | Deployment units targeted at it |
WaitCheckIn means the cluster is registered but its agent has not reported yet.
On a new site this is normal for the first few minutes. On an established site it
means connectivity, so check ArcNet tunnel status
before you look at anything else.
NotReady is different: the agent is talking, but the cluster is not in a state
that can accept work. That one is a cluster problem, not a network problem.
Deployment status
Each deployment unit reports its own state, and a unit targeting several clusters reports per-cluster. A unit is only as healthy as its unhealthiest target, so a single unreachable site will hold an otherwise fine deployment in a non-ready state. Drill into the unit to see which target is responsible rather than redeploying the whole thing.
Next steps
- App Store: what you can deploy
- Multi-Tenancy: how tenant configuration drives deployment mode
- ArcNet: the tunnels clusters connect over