On-call migrations
Embed
<a href="https://forumulate.com/p/watchtower/docs/oncall"><img src="https://forumulate.com/api/public/orgs/watchtower/spaces/docs/pages/b3013f91-a20d-4e2b-b490-fe47e11b0c1e/social-card.svg?v=3e7ae33eec8b" alt="On-call migrations" width="600" height="315"></a>VO_ID=... VO_KEY=... wtctl import victorops --api-id-env VO_ID --api-key-env VO_KEY [--apply]
wtctl import grafana-oncall --token-env GO_TOKEN --url https://oncall.example.com [--apply]Both import schedules and escalation policies, matching vendor users to project members by email; users who are not members are reported and left out. Contact methods are never imported by these two commands.
VictorOps
One Watchtower schedule per rotation group (UTC), one layer per shift; the turn length comes from the first roll and must be 1 hour to 30 days. Policies map their steps to levels; a step's timeout is the wait before the next level. Email, webhook and other entry types are listed as unsupported.
Grafana OnCall
Web schedules with rolling_users shifts (hourly, daily, weekly, monthly frequencies). iCal and calendar schedules are listed as unsupported. Escalation chains map notify_persons, notify_on_call_from_schedule and wait; other step types are listed.
PagerDuty and Opsgenie keep their own commands (wtctl import pagerduty|opsgenie), which write unless --dry-run is given.