HaloPSA On-Call: What Halo Does Well, and the After-Hours Rotation Gap It Leaves

It is 2:11 AM and a firewall at your largest client just stopped responding. Your monitoring raised the alert, HaloPSA turned it into a well-formed ticket, an auto-assign rule dropped it onto the right team, and the SLA clock started ticking against the correct priority. Halo did everything it was configured to do, and it did it cleanly. And yet no phone rang, because the rule assigned the ticket to a team, and a team is not a person you can wake up. That is the honest shape of HaloPSA on-call today: HaloPSA is genuinely good at organising after-hours work, but it was built to route and track tickets during a working day, not to decide which single engineer gets paged right now and keep paging until someone answers.

HaloPSA earns a lot of goodwill here, because it gives you more to work with than most PSAs do. This guide credits Halo fully for what it does well, shows exactly where the on-call rotation gap opens up — a different-shaped gap from the ones ConnectWise Manage and Autotask PSA leave — and lays out what closes it, including a bidirectional PSA sync that keeps HaloPSA as your system of record.

What HaloPSA genuinely does well

Start with the strengths, because Halo has real ones. HaloPSA's automation features include auto-assign rules that route incoming tickets to a particular person or group and set the status by criteria, a notification engine that can send alerts to agents by email, text message to mobiles, and tools like Slack, and automatic ticket scheduling that raises recurring tickets for planned events such as maintenance checks. On top of that, Halo's SLA engine runs on configurable workdays and business hours, with escalation rules and breach notifications that fire as a clock runs down. And for planned bookings there is Agent Resource Booking, part of Halo's Calendars and Appointments module, which lets a customer grab a slot with an available agent without the back-and-forth of email.

That is a strong, coherent toolkit, and plenty of MSPs run their whole service desk on it very happily. None of it, though, is an on-call rotation — and that is not a criticism, it is a different job. Every one of those features is built around planned work: tickets routed to teams, appointments booked into calendars, SLA clocks measured against business hours. On-call is the opposite shape. It is unplanned work arriving at 2 AM, where the only questions that matter are who is responsible this exact minute, how do we reach them fast, and what happens if they don't answer. Halo was not designed around those three questions, so teams approximate them with the pieces Halo does have — and that is where the seams show.

Where the on-call rotation gap opens

The Halo gap is sneakier than a PSA with no automation at all, precisely because Halo automates so much. Tickets get created, rules fire, SLAs escalate — it all feels covered. The trouble is that every one of those mechanisms points at a fixed target or a countdown, never at whoever the rotation says is carrying the pager tonight.

Halo's scheduling is built around tickets and appointments, not a rotation

Halo's booking is genuinely useful, but it is anchored to tickets and calendar slots. As the scheduling specialists at TimeZest put it plainly, in Halo "you can't book unless there's a ticket." That is exactly right for planned service work — you want appointments tied to real tickets. But an on-call rotation is not a booking. It is a standing answer to "who is responsible right now," independent of any single ticket, that has to absorb swaps and leave without someone editing a calendar. Halo has no object shaped like that.

Auto-assign and notifications point at a fixed target, not tonight's engineer

Halo's auto-assign rules and notifications are excellent at getting a ticket to the right place: a team, a queue, a named resource, an account manager. Those are constants. A rule has no concept of a rotation, so it cannot look up who is on-call this week, and it cannot try a second person and then a manager if the first one sleeps through the notification. It routes, once, to whoever the rule names — which is precisely what planned assignment needs, and not quite what a 2 AM page needs.

An SLA is a clock, not a page-until-answered ladder — and the market proves it

Halo's SLA escalation is real, but it escalates a clock: as the response or resolution timer runs down, it raises priority and fires breach notifications. That is invaluable for accountability. It is not the same as a paging ladder that reaches a live human, waits a set number of minutes, and moves to a backup if nobody acknowledges. The clearest proof that this is a genuine gap and not an oversight is that a whole market exists to fill it: dedicated on-call platforms such as ilert and OnPage build HaloPSA integrations specifically to route tickets to on-call responders with escalation policies. Halo is a strong PSA that plays well with those tools; the routing-to-a-human piece is simply not something it does on its own.

What breaks after hours

Trace that 2:11 AM firewall alert through the stack and every seam gives a little. Monitoring raises the ticket — the part that works. Auto-assign routes it to the after-hours team, which is a group, not a person on call. The SLA clock starts ticking, but a clock does not wake anyone; it just records how long the silence lasted. The notification emails the team inbox that nobody is watching at 2 AM. By the time the client's early staff notice the outage and start calling, an hour of the SLA is already spent — and because nobody was actually working the ticket overnight, the day shift picks it up cold at 8 AM.

None of those were technical failures; the monitoring and the PSA both did their jobs. Every breakage was an ownership and hand-off gap — the same class of problem that makes tickets get lost between engineers at every shift change, except an unattended alert is usually attached to something actively on fire. And the stakes are not abstract: in Uptime Institute's 2024 outage analysis, more than half of significant outages now cost over US$100,000. The minutes lost to "who's on-call again?" are billed at that rate.

What real on-call scheduling needs

A working on-call layer sits alongside HaloPSA and adds the four properties that auto-assign rules, appointments and SLA clocks can't provide between them.

• Rotation as a first-class object. One authoritative schedule that knows who is on-call at any given minute, absorbs swaps and leave without a manual calendar edit, and is the single source every alert reads from.
• Routing to the person, not the team. An alert reaches whoever the rotation says is responsible now — by SMS, push, voice call or chat — instead of landing in a shared queue to be noticed.
• Escalation until acknowledged.If the first engineer doesn't answer within a set number of minutes, it moves to a second channel, then a backup, then a manager, and it keeps going until a human explicitly acknowledges.
• A record that survives the shift. Who was paged, when they acknowledged, what they did, and what is still open at hand-off — captured as it happens, not reconstructed from a chat thread the next morning.

The routing and escalation mechanics are well-trodden ground; RMM alert management covers them in depth. The part almost nobody closes is the loop back into the PSA, and carrying the unfinished work into the next shift.

Closing the loop with HaloPSA + Shiftctl

This is where an MSP-built tool fits neatly beside Halo. On the Shiftctl Enterprise plan, the on-call rotation and the alerting layer are one system, and it talks to HaloPSA in both directions:

• An alert from your monitoring routes to whoever the rotation says is on-call, and escalates over SMS, voice call (press 1 to acknowledge), Slack, Teams, email and push until someone answers.
• Shiftctl creates or updates the matching HaloPSA ticket and, where it can match the engineer's email to a Halo agent, assigns it — so the ticket has a real owner instead of sitting against a team.
• Status syncs both ways: acknowledge or resolve in Shiftctl and the HaloPSA ticket moves with it; change the status in Halo and Shiftctl reflects it. Engineer updates post back as internal ticket notes, so Halo stays the system of record.
• Anything still open at sign-off carries into the next engineer's on-call handover brief instead of dying in a team queue — the day shift starts already knowing what is still burning.

There is a natural fit here beyond the feature list. HaloPSA is a British-built PSA with a strong following across the UK and Australia, and Shiftctl is built in Australia, runs on the same working-day clock, and prices in plain USD per user — so the timezone and billing overhead that comes with a US-centric pager doesn't apply. If your paging runs on SMS, voice and chat, Shiftctl Enterprise can be the standalone on-call layer beside Halo rather than a second heavyweight subscription bolted on top.

Getting from Halo workflows to a real rotation

• Keep your Halo auto-assign rules and SLAs — the routing-to-a-team and the SLA clocks are still doing useful work
• Write down who is actually on-call for the next four weeks — the real answer, not the stale roster
• Define your after-hours severity contract: what pages immediately, what waits for morning
• Point your alerts at the rotation and send a test page end-to-end, including an escalation to the backup
• Connect HaloPSA so pages create, assign and sync tickets automatically
• Keep Halo's SLA breach notifications — they are still the right way to hold response times accountable

Frequently asked questions