There's a Jira ticket that has been open since 2018. It asks for something so ordinary that most admins assume it must already exist: remind approvers when a service-desk request is waiting on them. Hundreds of votes. Hundreds of watchers. Still open.
Here's what actually happens when a Jira Service Management request enters Waiting for approval: Jira sends each approver exactly one email. If that email lands during a holiday, gets swept into a mail rule, or simply arrives on a busy Tuesday — that was the whole notification plan. The request will now sit in Waiting for approval until a human notices, forever if necessary. No follow-up, no summary, no “this is still waiting” anywhere in the approver's world.
The requester, meanwhile, assumes the process is working. The approver assumes there's nothing outstanding. Both are wrong, and the SLA clock doesn't care.
Why this gap exists
Approvals in JSM are a workflow feature, but notifications are a platform feature, and the two barely talk. The approval step fires its notification once, on entry. Jira's notification scheme has no event for “still pending after N days” — there is nothing to hook. This is why the request has been open since 2018: fixing it properly means teaching the notification system about time, and that's a deep change to ship for one feature.
The automation workaround — and its real costs
The standard advice is a scheduled Automation rule: run a JQL query for issues in Waiting for approval older than some threshold, and comment or email. It works, sort of, and if it covers your needs, genuinely: keep it. But teams who run it discover the costs one by one:
- It doesn't know who's pending. The rule can't easily tell which approvers have already answered on a multi-approver request, so it nags everyone or a hardcoded someone.
- Its message has no buttons. Jira's real approval email carries one-click Approve/Decline. The automation's comment or email doesn't — the approver still has to find their way in.
- It never stops. No reminder counter, no stop condition, no escalation path — unless you build state machines out of custom fields, which someone then has to maintain.
- It's per project. Every project needs its own copy of the rule, and every workflow rename silently breaks the JQL.
- It doesn't notice broken approvers. If the approver's account was deactivated last month, the rule will remind that account monthly, forever.
What a real fix looks like
Whatever you use — automation, an app, or a human with a spreadsheet — a complete answer to stuck approvals has five properties. It targets only the approvers who haven't answered. It can re-deliver the actual approval email, buttons included. It stops when someone acts and caps how often it nags. It escalates to a named human when polite reminding fails. And it notices when an approver can no longer answer at all — the deactivated-account case that quietly kills approvals in every growing company.
Full disclosure: we build Approval Nudge, a small Forge app that does exactly this list — hourly scan, targeted reminders, native approval-email resend, escalation, deactivated-approver detection — and nothing else. It runs entirely on Atlassian's infrastructure and is free for sites up to 10 JSM agents, so small teams never pay. If the automation rule serves you well, you don't need it. When the rule's costs start showing, it exists.
Where this series goes next
This piece covered the reminder gap. But in the twelve months of community questions we analysed, the biggest approval pain isn't reminders — it's controlling who is allowed to approve in the first place: restricting the approver field, mapping approvers to conditions, stopping requesters from picking a friendly face. That's the next post. It has nothing to do with our app; it's just the guide we wished existed.
Questions about a stuck-approval situation we didn't cover? Tell us about it — the interesting gaps become posts, and occasionally products.