Shiftctl Documentation

Severity levels (P1–P4)

Every alert lands with one of four severities, mapped automatically from the source system’s priority. Severity drives routing (policies can match on it), display order, and how hard the escalation pages.

Setting up your first integration

Go to Alerts → Integrations → Add integration and pick the source: PRTG, N-able N-central, N-sight RMM, ConnectWise RMM (Asio), ConnectWise Automate, or a generic webhook for anything else (Datto RMM connects through it with a ready-made recipe). N-sight, ConnectWise RMM, ConnectWise Automate and the Datto recipe are in beta. They are built from the vendors’ API documentation but not yet verified against a live tenant, so trigger a real alert from the source and confirm it looks right before relying on them for paging. For webhook sources, Shiftctl generates a unique webhook URL to paste into the source’s notification configuration. N-sight and ConnectWise RMM have no webhooks, so they connect the other way round: paste in API credentials and Shiftctl polls them every five minutes. Either way, use Send test alert to prove the loop end-to-end. The test flows through the real pipeline and appears on the dashboard like any production alert.

Duplicates are collapsed automatically. A re-firing monitor updates the original alert instead of paging again, and if a duplicate arrives at a higherseverity the open alert is escalated to match. When the source sends a recovery event the alert resolves itself, so configure a resolution trigger in the source too (PRTG’s Up trigger, N-central’s return-to-Normal). For sources that never send recoveries, each integration has an optional auto-close window; a per-integration silence watchdog can also raise an alert when a source goes quiet for too long, catching a dead webhook or broken configuration before you miss a real page.

Routing policies

Policies decide which alerts page whom, and how hard. Each policy is a set of conditions (severity, source, client, title keyword, and an optional time window, where overnight windows like 18:00 to 08:00 are supported) plus the escalation policy to run and an optional client tag. Policies evaluate top to bottom; the first match wins, so put specific policies above general ones. If nothing matches, the alert falls back to an email to the current on-call engineer, and no alert is ever silently dropped.

The condition set is deliberately small and closed. That is what keeps policy evaluation debuggable: the alert timeline records exactly which policy matched and why, so “why did/didn’t I get paged?” is always answerable from the alert itself.

Escalation policies

The ladder an unacknowledged alert climbs. Each step defines a delay, recipients (the current on-call engineer from your schedule, specific members, or both), and channels. The classic shape: step 1 pages on-call via SMS and push immediately; step 2 pages again plus Slack after 5 minutes; step 3 notifies the whole team after another 10. The final step can repeat on an interval until someone responds.

The on-call integration is the point:“notify on-call” resolves against the live Shiftctl schedule at fire time, so cover changes and swaps are automatically respected. Acknowledging from any surface (the web dashboard, the Slack button, an SMS reply, the email link) stops the ladder instantly and identically.

Maintenance windows

Patch night without pages. Schedule a window under Alerts → Maintenance (one-off or repeating daily/weekly, covering all sources or specific ones) and alerts arriving inside it are recorded as suppressed: visible in history, counted in reporting, paged to nobody. There is also a global pause switch under Integrations → Alerting for the storms no window anticipated.

Heartbeat monitors

Heartbeats invert the pattern: instead of firing when something breaks, they fire when something that should happen regularly doesn’t. A backup job, sync script or scheduled task pings a unique URL on every successful run (curl -fsS <url> as its last line); if the expected interval plus grace period passes with no ping, Shiftctl raises an alert through your normal routing. The next successful ping resolves it automatically.

SMS & notification channels

Escalation steps can page via email, SMS, voice call, Slack and web push. SMS and voice require each engineer to verify their mobile once under Manage → Account using a six-digit code by text, and pages are only ever sent to verified numbers. Replying ACK to an SMS page acknowledges the alert from the phone; on a voice call, press 1 to acknowledge. An unanswered call is retried once a minute later, then the escalation ladder continues. Slack pages arrive as direct messages with an Acknowledge button; Slack accounts link under Manage → Slack.

Owners can check the channel-readiness matrix under Integrations → Alerting: for every engineer, exactly which channels can actually reach them, before an escalation step depends on it.

Alerts in the handover

This is the part no standalone alerting tool has. Alerts attach to the active shift and appear live in the shift workspace. At handover, any alert still open becomes a mandatory step in the wizard: the outgoing engineer must resolve it or explicitly carry it forwardinto the handover brief. Carried alerts appear in the incoming engineer’s brief with severity and full context, and stay visible on My Shift in the “Handover from previous” card. An alert can survive a shift change, but it can never be silently dropped by one.

Client Insights & QBR reporting

Data Hub answers “how is my team doing?” and Alerts → Insightsanswers “which clients are noisy, whose infrastructure is unreliable, and who is burning my techs?” Five reports over 30/90-day windows, per client:

Plans & upgrades

Start with a 14-day free trial (full access, no credit card required), then choose a Team or Enterprise plan when you're ready. Switch between Team and Enterprise at any time. Upgrades take effect immediately with prorated charges. Downgrades take effect at the end of your billing period, so you keep full access until then. The confirmation modal shows the exact amount, what you are gaining or losing, and your next billing date.

Seat management

All paid plans support unlimited members. Seats are billed per user per month (or per year on annual billing). Add seats at any time, and the prorated cost is charged immediately. Remove seats and the credit appears on your next invoice. You cannot reduce seats below your current number of active members, so deactivate users first from Team → Members.

Invoices & billing history

View all past invoices, download PDFs and receipts, and see your projected next charge from Manage → Billing → View billing history. Each invoice shows a line-item breakdown including proration credits, refunds, and account credits applied.