Operations
Availability
Section titled “Availability”Availability on this platform has two layers.
Engine availability follows from the protocol: an engine keeps operating while no more than f of its 3f + 1 nodes are unavailable. At the minimum size of four nodes, one node may be down with no service interruption.
Node availability is contractual. Each node provider is required to maintain 99% node availability per calendar month, measured as the node being operational, online, responsive and able to process transactions. Failure to meet it is grounds for immediate termination of that provider’s agreement.
The composition of the two is what a client actually experiences, and it is better than either figure alone: a four-node engine tolerates one node being in its 1% downtime window without any effect on the service.
Neither layer covers a protocol upgrade. That takes the whole engine down for a couple of minutes, independently of how many nodes are healthy — see Updates.
Monitoring
Section titled “Monitoring”Swiss Subnet operates tooling for engine and node monitoring: engine status, transactions and canister visibility; node health, replication and consensus participation; and automated alerting on node degradation and health thresholds.
Clients get access to that tooling for their own engines. Monitoring is not an internal view reported outward; the same interface Swiss Subnet operates on is the one a client uses to see the state of the engine they run.
What it does not provide is host-level or in-canister instrumentation. No observability agent runs on a node or inside a canister, so application-level metrics are whatever the application itself exposes — see Interfaces.
Deployment control
Section titled “Deployment control”Deployment control is the real administrative boundary of the platform. Whoever can upgrade a canister can change any behaviour it has, including its authorisation rules — which makes this a more consequential permission than any application-level role.
Swiss Subnet provides tooling for role-based control over deployments, audit-logged by default, and designed to allow shared control of a workload by mutually distrusting parties.
Updates
Section titled “Updates”Two distinct things get updated and they follow different rules:
| Update type | Affects | Initiated by |
|---|---|---|
| Node and protocol updates | The engine itself | The protocol, executed by node providers |
| Canister upgrades | The client’s application | Whoever holds deployment control |
For node and protocol updates, node providers are contractually required to respond to and begin acting on a Swiss Subnet request — including hotfixes and redeployment — within 24 hours, with both physical and remote access to the machine available in that window.
An update takes the engine down for a couple of minutes. Replication does not make it transparent: an upgrade is a short scheduled outage, not an event a client’s users can be expected to miss.
A client cannot defer one today. Protocol and GuestOS upgrades reach a running engine through NNS proposals, over which neither the client nor Swiss Subnet AG has a veto. Planned: upgrades become opt-in per engine, so the engine owner decides whether and when to take one — see Governance.
Rollback
Section titled “Rollback”A canister upgrade is rolled back by restoring a snapshot taken before it. Restoring returns the canister’s code and its state to the moment the snapshot was taken, so everything written since is discarded — there is no merge, and no way to keep post-upgrade state while reverting the code. Rollback is therefore something to arrange before the upgrade, not after: a snapshot that was never taken cannot be restored, and the canister has to be stopped for both operations. See Data export for what a snapshot contains and how many are held.
A node or protocol update can be rolled back. The mechanism is part of the Internet Computer Protocol. A rollback reaches a running engine by the same route the upgrade did, as a change to the protocol version pinned for that engine — an NNS proposal today, see Governance.
Managed node operations
Section titled “Managed node operations”For clients running their own node infrastructure, Swiss Subnet offers the full lifecycle as a service: hardware sourcing and provisioning to specification, racking, networking and bootstrapping into a running engine, continuous health and security monitoring, and ongoing patching, upgrades, hardware swaps and incident response with Swiss Subnet as single point of contact.
This is relevant to organisations that want nodes on their own premises or in their own colocation, rather than consuming an engine assembled from Swiss Subnet’s provider network.