There is a particular kind of ticket that costs more than it should. It is filed correctly, it has a good description, it is in the right project, and it has nobody's name on it. It sits in the queue for two days because everyone who looks at the board assumes someone else has it. Then a customer follows up, someone notices, and the fix takes twenty minutes.

The gap was never engineering time. It was ownership. And ownership is the one thing your on-call rota already answers, continuously, for every team you run — it just does not reach the tracker where the work actually lives.

Why unassigned queues fail quietly

Alerts have a well-understood escalation model. If a page is not acknowledged in five minutes it goes to the next person, then to the manager, then to the whole channel. Nobody would ship an alerting setup where an unacknowledged page just sat there indefinitely.

Ticket queues have no such model. A bug report with no assignee generates no notification, breaches no policy, and appears on nobody's list of things they personally owe. It is visible to everyone and owned by no one, which in practice means it is invisible.

This matters more than it used to, for a boring structural reason: the number of places a ticket can come from has multiplied. A bug can now arrive from a customer in Intercom, from an error tracker filing into triage, from a form in Slack, from a QA engineer in Jira, or from an internal service calling an API. Each of those paths was built separately, and most of them create the issue without an assignee because whoever built the integration did not know who to put there.

The three bad workarounds

Teams usually reach for one of three things before they solve this properly.

Assign to a team, not a person. Jira components, Linear teams, Intercom teams. This is better than nothing and it is where most teams stop. But a team assignment is a routing decision, not an ownership decision. It tells you which queue the ticket is in; it does not tell you whose afternoon it is.

Triage in standup. Someone reads the unassigned list every morning and hands things out. It works, and it costs a daily meeting slot plus a full day of latency on anything filed after standup. It also breaks entirely the moment that person is on holiday.

A rotation spreadsheet that nobody reads. The rota exists, it is correct, and it is in a document that is not open when the ticket is created. The information is there and it does not reach the decision.

The shape of the fix

The fix is not complicated. At the moment a ticket is created, ask one question — who is on call for this team right now — and write the answer into the assignee field. Everything else is plumbing.

The reason it is worth doing carefully is that the question has a harder answer than it looks. "Who is on call" is not a static list. It changes at shift boundaries, it changes when someone takes an override for a dentist appointment, it changes when two people swap a weekend, and it changes when a holiday calendar removes someone from the rota. A hard-coded assignee is wrong within a week. A rota that respects overrides and swaps is right continuously.

Pagerly exposes that answer as a single call:

curl --location 'https://api.pagerly.io/pagerly/o/currentusers?teamname=devops' \
  --header 'X-APIKEY: <API-KEY>'

[
  {
    "name": "mansi",
    "email": "mansi@pagerly.io",
    "id": "U04CTTV5Z6G",
    "imageurl": null
  }
]

The email is the join key to every other tool — Jira resolves it to an accountId, Linear to a user UUID, Intercom to an admin ID. The id is the Slack member ID, which is what you want if you also intend to mention the assignee in a channel rather than relying on the tracker's own notification.

Two integration styles

Once you have that call, there are two ways to use it, and most teams end up with both.

Native — the tool and Pagerly are connected directly, and Pagerly writes the assignee. This is the better path where it exists, because it survives changes to your automation setup and it handles the schedule sync for you. Linear's Triage Responsibility is the clearest example: Pagerly keeps a Linear time schedule in step with your rota, and Linear itself assigns triage issues to whoever holds the current shift.

API-driven — you call the endpoint from Jira Automation, Zapier, Make, n8n, or your own service, then assign using the tool's API. This is what you use when the ticket is created somewhere Pagerly does not sit, which is most places.

Time-based versus round robin

Before you wire anything up, decide which distribution model you actually want, because the two produce very different queues.

Time-based assignment gives every ticket in a shift to the person holding that shift. If thirty bugs land on Tuesday afternoon, one person gets all thirty. This is right when the on-call role is "you own production today" and the volume is low enough that the same person handling everything creates useful context — they start noticing that four of those bugs are the same bug.

Round robin advances the queue on every assignment, so those thirty bugs are spread across the rota regardless of shifts. This is right for support volume, where the goal is balanced load rather than continuous ownership, and where each item is genuinely independent.

The failure mode of choosing wrong is specific in each direction. Time-based with high volume buries one person. Round robin with genuinely related work scatters six symptoms of one root cause across six people who each debug it separately.

Pagerly supports both, and exposes them through the same endpoint — so you can change the model later without touching any automation you have written.

What to do when nobody is on call

This is the part most implementations skip, and it is the part that turns a working automation into an incident six months later.

If a team's schedule has a gap — a rotation that has not started, a weekend nobody covers, an hour between shifts that the timezone maths left empty — the endpoint returns an empty array. Your automation now has no assignee to write, and if you did not plan for it, one of two things happens: it writes an empty value and the ticket is silently unassigned exactly as before, or it errors and the ticket creation fails.

Decide explicitly, per queue:

Fall back to a named person — a team lead or an escalation contact. Simple and it always works, at the cost of one person quietly accumulating out-of-hours tickets.
Fall back to a team or usergroup — the ticket is still owned by a group with an SLA, and the next person on shift picks it up. Good for support queues.
Leave it unassigned and alert — post to a channel saying the rota has a gap. This is the honest option: it surfaces the schedule problem rather than papering over it.

What you should not do is let it fail silently. Alert on a non-200 from the endpoint, and alert on an empty result if your rota is meant to have continuous cover.

The email-matching problem

The other thing that breaks quietly is identity. Pagerly resolves users by email, and so does every assignment API downstream. If someone's Slack email is alice@corp.com and their Atlassian account is alice.smith@corp.com, the lookup returns nothing and the ticket goes unassigned.

This is worth auditing once, properly, before you roll out: for every person on every rota, confirm the email Pagerly has matches the email in Jira, Linear and Intercom. It is ten minutes of work that prevents a class of bug that is genuinely annoying to diagnose, because the automation reports success and the assignee field is just empty.

The related trap: being on call does not create a seat. A contractor on the support rota who has no Linear licence cannot be assigned a Linear issue, and the API will tell you so in a way that is easy to swallow in a try/catch.

Per-tool guides

The mechanics differ enough per tool to be worth their own walkthrough:

Assign Jira tickets to the current on-call — Jira Automation, the REST API, and the one checkbox that silently breaks the rule.
Assign Linear issues to the current on-call — Triage Responsibility, and the GraphQL path for issues that never enter triage.
Assign Intercom conversations to the current on-call — admin resolution, conversations versus tickets, and replying from Slack.

The second-order benefit

The obvious win is that tickets get picked up faster. The less obvious one is that your rota starts telling the truth.

A rotation that only governs paging is exercised a few times a month, and gaps in it stay hidden until an incident finds them. A rotation that also assigns every bug and every support conversation is exercised continuously, so a mistake in it — a shift that ends an hour early, a person who left the company but not the schedule, a holiday calendar that never got imported — shows up as a ticket landing on the wrong person on a Tuesday, not as an unacknowledged page at 3am.

That is a much cheaper way to find out.

Read the developer documentation, or start with Pagerly.