Portal SLA Clocks shows customers the SLA times on their own requests, right in the help center portal. They see how much time is left, when it's due, and whether a target was met or missed. Atlassian's request for this, JSDCLOUD-325, has 660 votes and has been open since 2014.
A project admin picks which SLAs customers see. Internal targets stay internal.
The app adds a panel called "Service targets" to the request page in the portal. Each SLA a project admin picked gets one row with its name, a status lozenge and a short line of text.
| Status | Text on the portal |
|---|---|
| On track | 1h 30m left, Due by 6 Nov, 14:30 · Target 4h |
| Due soon | Same as On track, once 25% or less of the target time is left |
| Paused | Paused with 10m left, The clock is stopped for now · Target 4h |
| Overdue | Overdue by 30m, Target 4h |
| Met | Met in 45m, Target 1h |
| Missed | Missed, took 26h 5m, Target 24h |
The first part is the main line and the second is a smaller line under it.
Times come from Jira Service Management as they are. While an SLA is running, paused or overdue on a working-hours calendar, the row says "Counted in working hours", because 2 hours left might mean tomorrow morning. Met and missed rows don't carry that note, because Jira doesn't say whether a finished SLA ran on a calendar. Durations are shown in hours and minutes and are never turned into days, since a day means something different on every calendar. They're rounded down to the minute.
The due time is shown in the customer's own time zone. The panel says when it was loaded ("As of 14:30 your time") and has a Refresh button. It doesn't tick on its own, because a clock on a working-hours calendar stops outside those hours and the app can't know your calendar.
An SLA that hasn't started on a request (its start condition never matched) isn't shown. If a request was reopened, the panel shows the running cycle. Without one, it shows the result of the cycle that finished last.
Open Project settings in a service project, then Portal SLA Clocks. Project admins and Jira admins can do these things there.
Until someone saves, the portal shows "Time to first response" and "Time to resolution", the two SLA names most Jira Service Management templates start with. If your SLAs have other names, nothing shows until you pick them.
If the app can't read the saved settings, customers see a message that SLA times aren't available right now, and no SLA times. It never falls back to the two defaults then, so an SLA you removed or hid can't reappear. The settings page shows an error and no Save button when the read fails. If the saved record is damaged, the page says so, shows the defaults, and lets you save over it.
People can see the panel only on requests they can already open in the portal.
For customers, the app asks Jira as that customer whether they can open the request. Jira only lets customers read SLAs if they're agents, so after that check the app reads the SLAs as itself and passes on only the SLAs you picked.
Some portal users have an Atlassian account but no customer account, for example Jira users who raise IT requests. Forge doesn't let apps act as those users. For them the app reads the request as itself and shows the panel only if that person reported the request or is listed as a participant. A request shared with them only through an organization shows "This request isn't available to your account" instead. Anonymous portal visitors don't get the panel at all, because Forge doesn't offer this module to them.
The app runs on Atlassian Forge with no outside servers and no calls to other sites. It asks for three scopes.
| Scope | Why |
|---|---|
read:servicedesk-request | Check that a person can open the request, and find the service desk for a project |
read:jira-work | Read the SLAs on a request, check project admin rights, and list SLA fields on the settings page |
storage:app | Keep each service project's settings |
It can't change anything in Jira. It stores one settings record per service project (SLA names, names for customers and three switches). It doesn't store SLA times, request data or anything about people. See PRIVACY.md for details.
You'll need Node.js 22 and the Forge CLI.
npm install
forge register # replaces REPLACE_ME in manifest.yml with your app id
forge deploy -e development
forge install --product jiraRun the checks with npm test (unit tests), npm run validate (offline manifest check, plus a check that every module key exists in the Forge schema) and npm run check-frontend (UI Kit sources). The last two use the Forge CLI you have installed.
Use the support link on the app's Marketplace listing. Include the message the panel or settings page showed, and the request key if you can share it.
Zovo builds and maintains this app. If it saves you time, you can support the work on GitHub Sponsors. Sponsorship is optional, and the tool works the same without it.
Zovo is made by theluckystrike on GitHub.
If this app saves you time, you can support the work on GitHub Sponsors. Monthly tiers start at $5, and one-time tiers start at $15. Sponsorship is optional, and the tool works the same without it.