Scheduled Maintenance Windows

License: all tiers.

A maintenance window takes a member — or every member in a pool — out of DNS rotation for a fixed period and puts it back automatically, with no operator awake at 2 a.m. You schedule "disable at start, re-enable at end"; the gslbd scheduler does the rest.

Restore is precise: the window records exactly which members it disabled (only the ones that were enabled when it fired) and re-enables just those. A member you had already disabled by hand for an unrelated reason is left down.

How It Works

schedule window (start=T, end=T+d) ──▶ maintenance_windows table (rqlite)
                                              │
        gslbd scheduler polls every 30s on every node (no coordinator)
                                              │
   at T   → disable member(s), record which ones     → DNS drops them
   at T+d → re-enable exactly those members           → DNS restores them

The disable is claimed atomically so exactly one node performs it in a cluster; re-enable is idempotent and self-heals. A disabled member leaves DNS answers within the members-cache TTL (the scheduler also flushes the cache, so it is near-immediate). Because everything is recomputed from the persisted row, every node converges independently — the same no-coordinator design as rollouts and GitOps config.

Schedule a WindowWebUI

Open Maintenance under Infrastructure, or click Schedule Maintenance in a member's or pool's topology edit panel (which pre-fills the resource). Pick a start and end, and Schedule. The list shows each window's status (scheduled → active → completed) and a cancel button.

CLI

# Disable a member from 22:00 to 23:00 UTC tonightgslbctl maintenance schedule --type member --id mem-abc123 \  --start 2026-07-05T22:00:00Z --end 2026-07-05T23:00:00Z# Or give a duration instead of an end timegslbctl maintenance schedule --type pool --id pool-eu \  --start 2026-07-05T22:00:00Z --for 90mgslbctl maintenance listgslbctl maintenance cancel <window-id>

API

curl -X POST https://<api-host>:<port>/api/v1/maintenance-windows \  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \  -d '{"resourceType":"member","resourceId":"mem-abc123",       "startAt":"2026-07-05T22:00:00Z","endAt":"2026-07-05T23:00:00Z"}'

GET /api/v1/maintenance-windows lists them; DELETE .../{id} cancels one.

Permissions

  • maintenance:read — list windows (viewer and up).

  • maintenance:write — schedule and cancel (operator and tenant_admin).

Notes

  • Cancelling a window that has not started removes it cleanly. Cancelling one already in progress does not roll it back — the members stay disabled until you re-enable them manually (or leave the window and let it restore at its end).

  • Times are stored as absolute instants, so a window survives gslbd restarts and fires correctly across the cluster.

  • Deleting a member mid-window is safe: restore simply skips members that no longer exist.

  • Windows are diagnostic/ops scheduling and are not managed via Terraform — schedule them through the API, CLI, or WebUI.

Was this article helpful?