Skip to main content

Fleet Maintenance Windows & Update Policies

Edge systems, autonomous mobile robots (AMRs), interactive kiosks, and critical machines cannot be updated at arbitrary times. Applying an operating system swap or restarting a container workload during peak operation risks business disruption, mission aborts, or safety hazards.

Admiral provides native Fleet Maintenance Windows that control when automated rollouts and updates are permitted to execute.

1. Defining a Fleet Update Window​

Maintenance windows are configured per fleet via the dashboard under Fleet Settings > Update Policy or programmatically through the REST API:

PUT /v1/fleets/{fleetId}/update-window
Content-Type: application/json
X-Organization-ID: {orgId}

{
  "enabled": true,
  "timezone": "Australia/Sydney",
  "start_time": "02:00",
  "end_time": "05:00",
  "days_of_week": ["Monday", "Tuesday", "Wednesday", "Thursday"]
}
  • Timezone-Aware Scheduling: Evaluates schedules in the local operational timezone of the deployment (e.g. Australia/Sydney, America/New_York, or Europe/London).
  • Day & Hour Bounding: Constrains disruptive actions to low-traffic hours (e.g., 2:00 AM – 5:00 AM) or when autonomous robots are parked at base charging stations.

2. Pre-Flight Rollout Impact Calculation​

Before executing a staged rollout across hundreds or thousands of devices, Admiral allows engineering teams and automated CI/CD pipelines to calculate the deployment impact:

POST /v1/rollouts/impact
Content-Type: application/json
X-Organization-ID: {orgId}

{
  "fleet_id": "976acb62-3f36-4ba3-81f6-a8b7fbd350b8",
  "target_version_id": "v2.14.0",
  "force": false
}

The impact API evaluates:

  1. Eligible Devices: Total online machines currently matching the target hardware architecture and fleet tags.
  2. Maintenance Window Gate: How many devices are currently inside an active maintenance window vs. queued for the next window.
  3. Pending Actions: Devices currently performing health checks, active battery discharging, or mission-critical tasks.

3. Maintenance Window Enforcement​

When a rollout begins:

  • Devices In-Window: Proceed through canary batching immediately. The active A/B slot or container workload updates, boots, and completes health verification.
  • Devices Out-of-Window: Placed in a QUEUED_MAINTENANCE state. The Admiral init supervisor holds the update until the device's clock enters the configured window.

Checking Window Status​

You can check whether updates are permitted on a fleet at any given moment:

GET /v1/fleets/{fleetId}/update-window/check
X-Organization-ID: {orgId}

Returns allowed: true if the fleet is currently within its maintenance window, or allowed: false with next_window_at: "2026-09-15T02:00:00Z".

4. Emergency & CVE Bypass (Out-of-Band Updates)​

When addressing zero-day security vulnerabilities (CVEs) or emergency operational bugs, administrators and CI/CD service accounts can issue a forced rollout:

POST /v1/rollouts
Content-Type: application/json
X-Organization-ID: {orgId}

{
  "fleet_id": "976acb62-3f36-4ba3-81f6-a8b7fbd350b8",
  "config_id": "cf-production-core",
  "force": true
}

Setting force: true instructs the Admiral manager to immediately bypass the maintenance window, deploy the update, and execute health checks without waiting for scheduled hours.