Deployment Rings

Deployment rings implement phased rollouts for update policies. Instead of deploying patches to your entire fleet at once, rings let you gradually expand coverage while monitoring for issues at each stage.

Ring concept

A deployment ring is a staged rollout strategy. Instead of deploying patches to every endpoint simultaneously, you define a sequence of rollout phases that gradually expand coverage. Updates flow through each phase in order, and if problems surface at any stage, you can halt the rollout before it reaches the rest of your fleet.

This approach reduces risk. A patch that causes application compatibility issues or performance degradation is caught early, where the impact is limited to a small number of non-critical endpoints.

Rollout phases

Each deployment ring has a customizable set of rollout phases. You define how many phases the ring uses, what percentage of agents each phase targets, and how the rollout advances between them. There is no fixed number of phases: a simple ring might use two phases, while a cautious enterprise rollout might use five or more.

A typical ring configuration might look like this:

But you can define any number of phases with any target percentages. The final phase is always a Complete phase fixed at 100% and pinned to the end of the pipeline, so every rollout finishes by covering your entire targeted fleet. You add, remove, and reorder the phases that come before it; the Complete phase stays last.

Presets

To help you get started, TridentStack Control provides built-in presets that populate a ring with a recommended set of phases:

Preset	Phases	Best for
Conservative	Canary (3%) -> Early Adopters (15%) -> Broad (50%) -> Complete (100%)	Production-critical environments. Longer wait times and manual approval gates at the Early Adopters and Broad phases
Moderate	Canary (3%) -> Early Adopters (30%) -> Complete (100%)	Most environments. Balanced phase count with automatic advancement
Aggressive	Pilot (10%) -> Complete (100%)	Environments that need rapid patching with minimal staging
Immediate	All Agents (100%)	No staging. Deploys to every targeted agent at once
Custom	Define your own	Start from scratch when none of the presets fit

Selecting a preset populates the ring's phases automatically. You can then customize individual phases or add and remove phases as needed. When you modify any phase after applying a preset, the ring switches to Custom mode.

Phase configuration

Each phase in a deployment ring has the following settings:

Setting	Description
Name	A label for the phase (for example, "Canary", "Early Adopters", "Full Fleet")
Target percentage	The cumulative percentage of agents this phase covers. The final phase must be 100%
Minimum agents	The minimum number of agents that must be targeted before this phase can execute
Advancement type	Automatic (advances after wait time and success conditions are met) or Manual (requires an administrator to click Advance)
Wait time	Hours to wait after the phase completes before advancing to the next phase. Gives you time to observe results. Not shown for the final 100% phase since there is nothing to advance to.
Success rate	The minimum percentage of successful installations required before the rollout can advance (automatic mode only)
Max failures	The maximum number of failures allowed before the rollout auto-halts (automatic mode only)

For how a rollout moves from one phase to the next relative to your deployment windows, see How a rollout advances.

Targeting modes

Each phase can target endpoints in one of two ways:

• Percentage-based (default) - TridentStack Control automatically selects a percentage of endpoints from the policy's target groups. Simple to set up but gives you less control over exactly which endpoints are in each phase.
• Tag-based - Target the endpoints that carry specific tags (for example, "Canary Ring" or "Early Adopters"). This is the recommended approach for maintaining consistent phase membership over time, because membership follows the tag rather than a recalculated percentage.

Deployment windows

Deployment windows control when updates are allowed to install. Each ring can have its own schedule independent of the update policy's maintenance window.

You define a window by a start time and a duration, rather than by separate day-of-week and time-of-day rules:

• Timezone - Set the timezone the window's start time is measured in.
• Start time - The day and time the window opens (for example, Wednesday at 10:00 PM).
• Duration - How long the window stays open (for example, 6 hours).

A window that runs past midnight is handled correctly: "Wednesday 10:00 PM for 6 hours" opens Wednesday at 10:00 PM and stays open until 4:00 AM Thursday, all as one continuous window.

A window can be up to 23 hours long. Each selected day opens its own occurrence of the window, so a longer duration would overlap the next day's occurrence. If you want a ring that can deploy at any time, remove its windows instead (see Always-active rings).

You can also block specific date ranges with exclusion dates (for example, company-wide code freezes, holidays, or change blackout windows). Each exclusion includes a reason for documentation, and no deployments run during an excluded range even if a window would otherwise be open.

Always-active rings

If you do not define a window, the ring is always active: deployments can happen at any time, around the clock. The ring editor flags this so it is never a surprise, and when you save an always-active ring it asks you to confirm, showing how many endpoints would be affected. Use an always-active ring only when unrestricted, around-the-clock deployment is intentional, for example on a dedicated pilot ring or test environment.

When a ring is always active, its status on the agent detail page shows Always open in place of a next-window time.

Because pre-staging, automatic safety halt, and per-window execution limits all depend on having a scheduled window to work against, those settings are unavailable on an always-active ring (see Additional ring settings).

What happens during and outside windows

TridentStack Control only performs disruptive actions during active deployment windows:

• Application update deployment - only dispatched when the window is open
• Microsoft Office update deployment - dispatched after application updates complete and before system updates begin, when the window is open and the assigned policy has Office ring deployment enabled
• System update deployment - only dispatched when the window is open
• Feature upgrade dispatch - Windows build upgrades (for example, 24H2 to 25H2) are dispatched through the same ring phases as other updates when the update policy has feature upgrades enabled. See Feature upgrades for how the upgrade itself runs on the endpoint.
• Driver update deployment - only dispatched when the window is open
• Scheduled restarts - only executed when the window is open

If an application deployment finishes and the system update phase is ready, but the deployment window has closed, the system updates will wait until the next window opens. Similarly, if a scheduled restart time arrives but the window is closed, the restart will wait.

Non-disruptive actions (settle timer countdown, timeout cleanup, failure marking) continue regardless of window state. These are housekeeping operations that do not affect the endpoint.

Dispatch order within a window

When a ring fires for an agent during an active window, updates are dispatched in a fixed order. Each stage runs to completion (with a configurable settle time between stages) before the next stage begins:

1. Application updates - third-party application installs and upgrades through the agent's package manager integration.
2. Microsoft Office updates - Click-to-Run Office channel/version reconciliation through the agent's built-in Office updater. This stage runs for Windows and macOS endpoints whose assigned system update policy has both Enable Office Updates and Enable ring deployment for Office updates turned on, and only when the agent is not already at the policy's target version. Office is dispatched here, ahead of system patches, so it completes before any reboot the system stage triggers.
3. System updates - operating system patches. On Windows this is Windows Update content (security and quality cumulative updates, monthly rollups). On macOS this is Apple system updates (Safari, command-line tools, and security responses through Apple's update service). On Linux this is the configured package manager's available updates.
4. Driver updates - Windows driver content from Windows Update (only when the policy has driver updates enabled and ring deployment for drivers enabled).
5. Feature upgrades - major version transitions. On Windows this is build upgrades (for example 24H2 to 25H2). On macOS this is major OS upgrades (for example Sonoma to Sequoia, when policy permits). Feature upgrades always run last because they typically require a reboot.
6. Automatic restart - if any of the above stages indicates a reboot is required and the ring permits auto-restart, the reboot is dispatched after all install stages complete. Restarts are staggered across the ring to avoid simultaneous reboots.

If a stage produces no applicable updates for a specific agent, that stage is skipped silently and the chain advances to the next stage. For example, an agent with no applicable Office update simply moves from the application settle into the system stage without an intervening Office dispatch.

If a stage fails for an agent, the execution halts at that stage and the agent is excluded from further work in the current window. The next window starts fresh.

Window lifecycle states

Each deployment ring tracks its window lifecycle to provide clear visibility into what the ring is doing at any given time:

State	Meaning
Scheduled	The deployment window is closed. No deployments are occurring. The ring is waiting for the next window to open.
Active	The deployment window is open and the ring is actively deploying updates to agents.
Idle	The deployment window is open, but the ring has no remaining actions to perform. All eligible agents have been deployed, and there are no pending system update dispatches or reboots.

How transitions work:

When a deployment window opens, the ring enters the Active state. As agents receive their updates and no more work remains, the ring transitions to Idle. If a new agent comes online or becomes eligible during the window, the ring moves back to Active. When the window closes, the ring returns to Scheduled regardless of its current state.

The Idle state does not mean the rollout is complete. It means the ring has done everything it can during this window. Agents that were offline, in cooldown, or not yet eligible may receive updates in the next window.

If an individual endpoint cannot install updates because of a problem on the device itself (most often low free disk space), that endpoint shows an amber Updates blocked indicator on its detail page in place of its normal deployment status. Select it to see the specific cause and how to resolve it. The indicator clears on its own once the underlying issue is fixed, and the ring resumes deploying to that endpoint automatically.

Next Dispatch and Next Window

On the Rollout Status tab, each ring shows one of two timing indicators so you always know what the ring will do next:

Indicator	When it appears	What it means
Next Dispatch	The window is open and the ring has real work to send to endpoints: updates queued to install, an install still in progress, or a phase that is ready to widen to its next group of endpoints.	A short countdown to the next moment the ring acts on an endpoint. This only appears when an install will actually happen soon.
Next Window	The window is closed, or the window is open but the ring has finished everything it can do this window (it has gone Idle).	The next time the ring's maintenance window opens, which is the next time installs begin again. It shows that upcoming window's real start and end times.

The two are mutually exclusive: if there is nothing left to install in the current window, Next Dispatch disappears and you see Next Window instead. In short, Next Dispatch answers "when will the ring next touch an endpoint?" (and only shows when the honest answer is "soon, with real work to send"), while Next Window answers "when do installs start again?"

A detail that sometimes causes confusion: Next Window always points to the next window that has not started yet. If a ring's window is open right now but the ring is Idle (no more work this window), Next Window shows the following window's real opening time, not the one currently open. To confirm a window is open at this moment, use the ring's lifecycle state (Active or Idle) or the Active indicator on the agent detail page, described above. Always-active rings have no scheduled window, so they show Always open in place of a next-window time.

How a rollout advances

A rollout moves from one phase to the next on its own observation schedule, while installs stay inside your deployment windows.

• A phase widens to the next stage as soon as that stage's wait time finishes and its success criteria are met. Wait times are measured in wall-clock hours, so a 24-hour wait always means 24 real hours.
• The actual installs for a stage happen during your next open deployment window. If a stage becomes ready while the window is closed, it waits until the window opens.
• If a ring is always active (no window), installs can happen at any time, so a rollout simply widens and deploys as each stage's wait completes.

This means a phased rollout finishes promptly even when your windows are sparse. With a weekly maintenance window and multi-day waits, for example, the rollout widens through its stages over a few days and installs each stage at the next window, rather than waiting a full week for every single stage.

Each phase card in the ring editor shows the projected date and time that phase is expected to begin, under your current schedule, stages, and wait times, with the projected completion time for the whole rollout shown beneath the phases. The projections update live as you adjust the ring, so you can see the whole rollout before you save.

A phase set to manual advancement is the exception: instead of widening automatically when its wait completes, it waits for an administrator to approve the next stage. Installs still happen during the next open window.

Per-update-type canary validation

When a ring's early (canary) phase rolls out, TridentStack Control validates each kind of update on its own. If the early endpoints include both application updates and system updates, the rollout confirms each kind succeeds before widening to more endpoints. If a kind of update is failing its early validation, the rollout pauses widening that ring and the Rollout Status page shows which kind of update is holding it, instead of letting other successful updates hide the problem.

Safety controls

Each ring includes configurable safety mechanisms to automatically halt a rollout if something goes wrong:

• Auto-halt by failure count - Halt the rollout if the number of failures exceeds a defined limit
• Auto-halt by failure rate - Halt the rollout if the failure percentage exceeds a defined threshold
• Manual override - Allow or block administrators from manually overriding an auto-halt to continue the rollout

Failed agent cooldown

When an agent fails during a deployment, it enters a per-window cooldown. The agent is excluded from further deployment attempts for the remainder of the current deployment window. When the next window opens, the agent gets a fresh start and is eligible for deployment again.

This prevents the scheduler from repeatedly retrying a failing agent every five minutes within the same window, while ensuring the agent is not permanently blocked. If the underlying issue is resolved (for example, a bug fix is deployed to the server), the agent will succeed on its next window.

If you need to retry a failed agent immediately within the same window, use the Re-deploy button on the Rollout Status tab to reset the ring's phase state and restart the deployment cycle.

Additional ring settings

Always-active rings

Pre-staging, automatic safety halt, and execution limits all rely on a scheduled deployment window to work against, so they are unavailable on an always-active ring (one with no window). They become available as soon as you give the ring a window.

Pre-staging

When pre-staging is enabled, agents download update files in advance during a separate download window, before the deployment window opens. This ensures updates are ready to install immediately when the deployment window starts, reducing the time agents spend in the maintenance window.

Pre-staging settings include download windows, retry attempts, bandwidth limits, and file retention period. Because pre-staging downloads ahead of an open window, it is only available on rings that have a deployment window.

Auto-restart

Configure whether agents automatically restart after installing updates. Settings include a prompt timeout (how long to wait for user acknowledgement before restarting), maximum postpone time, and reprompt interval.

Execution limits

Cap how many times a ring deploys to a single endpoint within one deployment window. Each deployment cycle (installing application updates, system updates, and any required restarts) counts as one execution. Once an endpoint reaches the limit, no further deployments are scheduled for it until the next window opens.

This prevents an endpoint from repeatedly installing, restarting, and redeploying within the same window. Because the limit is counted per window, it is only available on rings that have a deployment window.

Calendar view

The Deployment Rings page includes a calendar view that shows all scheduled deployment windows across your rings in a monthly grid.

Each deployment window appears as an event on the calendar with a color-coded status indicator:

Status	Description
Scheduled	The window is upcoming and has not started yet
In Progress	The window is currently active and deployments are running
Completed	The window finished and all deployments in that window are done
Awaiting Approval	The rollout reached a manual-advance phase and is waiting for administrator approval
Paused	The rollout was paused by an administrator
Halted	The rollout was automatically halted due to safety controls
Failed	The deployment window encountered errors
Skipped	The window was manually skipped by an administrator
Unassigned	The ring is not applied to any endpoints (shown with a gray dashed border). Check that the ring's target tags match active agents

Click any event on the calendar to see details including the ring name, current phase, time window, execution breakdown (completed, in-progress, pending, and failed counts), and phase advancement type.

From the event detail view, you can:

• Skip a scheduled window to exclude it from the rollout
• Restore a previously skipped window

The calendar refreshes automatically to reflect the latest rollout status.

Notifications

Deployment ring lifecycle events can trigger notifications to your team via Email, Slack, Microsoft Teams, Discord, or custom webhooks. Events include deployment started, phase advanced, approval pending, deployment completed, emergency halt, and phase failure. Configure which events trigger alerts and who receives them in Settings > Notifications. See Notifications for full setup instructions.

tip

Enable notifications for Approval Pending and Emergency Halt at minimum. These are the two ring events most likely to require immediate action.

Monitoring ring progression

The deployment rings list view shows each ring's status at a glance, including the current phase, success and failure counts, success rate, and time remaining before the next phase advancement.

Installs for each phase still happen during your next open deployment window; the diagram above shows how the rollout widens between phases.

Rollout completion and automatic restart

When a ring reaches its final phase and all targeted agents have been deployed, the ring checks whether any agents still have pending updates. If pending updates remain (for example, an agent was offline during the rollout or new updates became applicable), the ring stays active and continues deploying. It only marks itself as complete when no pending updates remain for any agent in the ring.

Once a rollout completes, the ring does not stop permanently. If new applicable updates arrive for agents in the ring while a deployment window is active, the ring automatically starts a new rollout cycle. This means rings with broad deployment windows (such as daily or continuous schedules) behave as perpetual rollout engines: any time a new patch is approved or a new update becomes applicable, the ring picks it up and deploys it through the configured phases without manual intervention.

For rings with narrower windows (for example, a weekly Wednesday 2:00 AM - 6:00 AM window), the ring waits in a completed state until the next window opens. If agents have new pending updates at that time, the rollout restarts automatically.

If you need to restart a completed rollout immediately without waiting for new updates to arrive, click the Re-deploy button on the Rollout Status tab. This resets the ring's phase state and begins a fresh rollout cycle on the next scheduler evaluation.

Controlling a rollout

Halting

If issues are detected at any phase, you can halt the rollout. Halting:

• Prevents advancement to the next phase
• Stops any pending installations on agents that have not yet started
• Does not roll back updates that have already been installed
• Keeps the rollout in a halted state until you take action

Rollouts can also halt automatically when safety controls are triggered (for example, when the failure count or failure rate exceeds the configured threshold). When an auto-halt occurs, a banner displays the halt reason on the ring's detail view.

warning

Rollback is not automatic. If a rollout is halted, updates that were already installed on earlier phases remain in place. If a patch needs to be removed, create a separate remediation plan for the affected endpoints.

Un-halting

To resume a halted rollout, click Un-halt from the ring's action menu or the table row. A dialog appears showing the halt reason and two options:

Option	Behavior
Continue deploying, skip failed agents	Failed agents are left in their current state. Deployment resumes with the remaining agents only
Retry failed agents and continue deploying	Failed agents are re-queued for another attempt. Recommended when the original failure was transient (for example, a network timeout that has since been resolved)

The dialog shows the count of failed agents in each option label so you can assess the scope before choosing.

An optional notes field lets you document what corrective action was taken. These notes are recorded for audit purposes.

info

If the ring is also paused, you must resume it separately after un-halting. The un-halt dialog displays a warning when this applies.

Pausing vs halting

	Pause	Halt
Trigger	Manual (administrator clicks Pause)	Automatic (safety controls) or manual
Resume	Click Resume at any time	Requires un-halt with a decision about failed agents
Pending installs	Stopped	Stopped
Completed installs	Not rolled back	Not rolled back

Use Pause for temporary stops (planned maintenance, investigation). Use Halt when failures need to be addressed before continuing.

tip

Assign your least critical endpoints to the earliest phases. Development machines, test servers, and lab systems are ideal candidates. If a patch causes issues, the impact is minimal and you catch the problem before it reaches production.

Cancelling pending executions

To stop a rollout entirely, you can cancel all pending executions. Right-click the ring and select Cancel Pending. A confirmation dialog warns that this action cannot be undone.

Cancelling immediately removes all agents in "pending" status from the rollout. Installations that are already in progress complete normally. Use this when you need an emergency stop, when a configuration error is discovered, or when you want to prevent remaining agents from being updated.

Viewing agent details

To see per-agent execution status for a rollout, click the ring's name on the Rollout Status page. This opens a dedicated rollout detail page.

At the top of the page, each rollout phase appears as a card matching the phase pipeline you configured in the ring editor. Each card shows the phase's live status, how many endpoints in that phase have completed or failed, and what the phase is currently waiting on: a soak countdown with its projected advancement time, the specific criterion holding it (for example, a success rate below the required minimum), or when it completed. On multi-phase rings, clicking a card filters the agents table below to that phase. When every phase has finished, a banner confirms the rollout is 100% complete and shows when it will automatically restart for the next update cycle.

Below the phases is a searchable table of all agents in the ring:

Column	Description
Hostname	The agent's system name
Phase	Which deployment phase the agent belongs to
Status	The endpoint's latest execution state in this ring
App / System	The per-channel result of the latest execution
Last Execution	When the endpoint's most recent execution started
Duration	How long the installation took

The info icon on the Status column opens a key defining every state. Most are self-explanatory (Completed, Failed, In Progress, Pending, Cancelled); two deserve special mention. Not Converged means the endpoint reported that an update installed successfully, but a later check found the update is still needed. TridentStack Control treats this as neither a success nor a failure: it automatically retries the update at the next deployment window, up to three attempts. Retry scheduled means the endpoint failed but the ring will automatically retry it at the next deployment window, so it is not a stopping point; its info popover shows the next attempt time and how many attempts have been made. Ordinary failures keep retrying every deployment window until they succeed. If the ring itself is paused or halted, a failed endpoint shows plain Failed instead, with an explanation that retries are on hold until the ring resumes.

Use the status filters at the top of the table to filter by state; filters for the rarer states (Retry scheduled, Not Converged, Abandoned) appear only when endpoints are actually in them. Type in the hostname search field to find a specific endpoint. The table is paginated for rings targeting large numbers of agents. Click a row to expand it for attempt history, installed updates, and the restart timeline, or click a hostname to jump straight to that endpoint's page.

Scheduled column indicators

The Scheduled column on the agent detail page shows the agent's current deployment ring status:

Indicator	Meaning
Active (green pulsing dot)	Deployment window is open and the ring is actively deploying
Idle (gray badge)	Deployment window is open but no actions are pending for this ring
Cooldown (amber badge)	This agent failed during the current window and will retry in the next window
Completed (green check)	The ring's rollout has finished
Halted (red badge)	The ring has been halted due to excessive failures
Paused (amber badge)	The ring has been manually paused
Next window time (blue clock)	The deployment window is closed; shows when the next window opens
Manual (gray badge)	No deployment ring is assigned; approved updates require manual installation (policy still controls what gets approved)

Managing rings

From the deployment rings list page you can:

• Duplicate a ring to create a copy with all settings (starts inactive)
• Export a ring as JSON for backup or sharing
• Import a ring from a JSON file (creates an inactive copy)
• Delete a ring that is not assigned to any policies