Disclosure: I’m the developer of SLA Pulse for Jira.
Until now, SLA Pulse used one set of SLA targets for the whole Jira site. That works for one team, but a support queue and an engineering project rarely want the same numbers. Version 2.9.0 is about fixing that, so each team sees SLA results that match how it actually works.
What’s new in 2.9.0
- Per-project SLA rules: each project can have its own targets by priority and issue type. Jira admins set the site default, and a project’s admins can set their own.
- Working-hours calendars: SLA time is counted only inside your team’s working hours, with holidays and time zone.
- Pause-the-clock statuses: choose statuses like “Waiting for customer”. Paused issues stop counting, show a Paused tag and are left out of Slack alerts.
- Clearer numbers: compliance is Met divided by Met plus Breached, and resolution time is shown as both mean and median.
- No new permissions are needed, and your existing rules carry over.
How to set it up for a project
- Open the app and choose your project with “Change project”.
- In Settings, set the SLA target for each priority. The defaults are Highest 12h, High 24h, Medium 36h, Low 48h and Lowest 72h. Change them to match your promises to customers.
- Choose your working-hours calendar (days, hours, time zone, holidays).
- Pick the statuses where the clock should pause, for example “Waiting for customer”.
A tip on pause statuses: only pause for statuses where the team really can’t act. If you pause too many, your compliance number will look better than your customers’ experience.
What the app does
- A compliance dashboard with health score, on track, near breach, breached and paused issues for the last 7, 30 or 90 days. “Near breach” means 25% of the SLA time is left.
- MTTA, MTTR and reopen rate, plus breach drivers with recommendations that explain what to act on.
- Optional Slack alerts and a daily digest, and CSV and PDF reports.
- It runs on Atlassian Forge inside Jira Cloud, so your data stays with Atlassian.
What it doesn’t do yet: it uses its own rules and doesn’t read Jira Service Management’s built-in SLA goals, and overnight shift calendars (for example 22:00 to 06:00) aren’t supported.
I’m a solo founder and would really like your input. How does your team handle SLA targets across projects today? And would overnight shift calendars matter for you?
Marketplace listing:
https://marketplace.atlassian.com/apps/3460167006/sla-pulse-for-jira
