Time-Based Routing Schedules

License: all tiers.

A routing schedule redirects a service to a different pool during a UTC time-of-day window — "between 08:00–18:00 UTC weekdays, route to pool A; otherwise fall back to the service's default pool." It's evaluated fresh on every DNS query against the server's UTC clock, so there's nothing to start or stop: the schedule just becomes active or inactive as time passes.

How It Works

schedule (service, pool, 08:00-18:00, weekdays) ──▶ routing_schedules table (rqlite)
                                                            │
                gslbd's DNS resolver checks active schedules on every query
                                                            │
       match found  → answer from the schedule's pool
       no match     → answer from the service's default pool

There's no background scheduler and no state to converge — the check is a cheap in-memory read (schedules are cached alongside the service/member lookup, same TTL) done at query time, so it adds no extra database round trip on the hot path.

If several schedules on a service are active at once, the one with the highest priority wins.

Add a Schedule

WebUI

Open a service's edit panel in the topology view — the Routing Schedules card lists existing schedules and lets you add one (pool, start/end time, weekdays, priority). A service with an active schedule shows a "scheduled" badge on its topology node.

CLI

# Business-hours routing: weekdays 08:00-18:00 UTC to pool-business,
# otherwise the service's default pool applies.
gslbctl services schedules add --service svc-abc123 --pool pool-business \
  --start 08:00 --end 18:00 --days 1,2,3,4,5 --priority 1

gslbctl services schedules list --service svc-abc123
gslbctl services schedules remove <schedule-id>

--days is a comma-separated list, 0=Sunday through 6=Saturday; omit it for every day. An overnight window (--end earlier than --start, e.g. 22:00–06:00) wraps past midnight.

API

curl -X POST https://<api-host>:<port>/api/v1/services/<service-id>/schedules \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"poolId":"pool-business","startTime":"08:00","endTime":"18:00",
       "weekdays":[1,2,3,4,5],"priority":1}'

GET /api/v1/services/{id}/schedules lists a service's schedules; DELETE /api/v1/schedules/{id} removes one.

Terraform

resource "nexus_schedule" "business_hours" {
  service_id = nexus_service.www.id
  pool_id    = nexus_pool.business.id
  start_time = "08:00"
  end_time   = "18:00"
  weekdays   = [1, 2, 3, 4, 5]
  priority   = 1
}

There is no update API for schedules, so changing any field replaces the resource (deletes the old schedule, creates a new one).

Permissions

schedule:read — list schedules (viewer and up).
schedule:write — add and remove schedules (operator and tenant_admin).

Notes

Times are UTC only — convert your local business hours before entering them.
The overnight-wrap weekday check applies to the start day for the whole span; the portion past midnight isn't re-checked against the next day's weekday list. This matters only if a schedule needs different weekday rules before vs. after midnight — split it into two schedules if so.
Deleting the pool a schedule points to does not delete the schedule; the schedule simply stops matching (the DNS resolver falls back to the service's default pool) once the pool is gone. Delete the schedule explicitly when retiring a pool.
Schedule changes take effect within one DNS cache TTL cycle (default 30s), not immediately — the schedule list is cached the same way as service/ member lookups.