The short version
What both apps do
Both solve the same gap. Jira Software has no native SLAs — that engine lives in Jira Service Management — yet plenty of work carries a deadline without needing a service desk around it. Both apps therefore compute a clock from the issue’s own change history, show its state on the issue, notify people as the deadline approaches, and report on the outcome.
Time to SLA describes itself on its listing as the “best-selling service level agreement (SLA) tracking app with solid configuration, reporting & search features”, and summarises the job as: define SLAs, see a countdown to the target date, and configure notifiers for issues close to critical time or just after breach. That is a fair description of what Pact does too. The disagreement between the two products is not about the goal.
The scale gap is real and worth stating first. Read from Atlassian Marketplace public data in August 2026, Time to SLA had roughly 3,378 active installs, 236 reviews and a 4.80 average rating. Pact is new. No amount of argument on this page changes that, and if a long review history is what your organisation needs, you already have your answer.
Where Pact differs
A working SLA before you configure anything
Open an issue, choose Apps → SLA, and Pact already shows a default SLA derived from that project’s own statuses. Nothing has been set up; the panel is populated because the app inferred a sensible starting point from the workflow it found.
This matters more than it sounds. The usual failure mode of an SLA evaluation is not that the app is bad — it is that somebody installs it, meets a blank policy editor, intends to come back to it, and never does. Starting from something you correct is a different experience from starting from something you must author.
Alerting that is opt-in, and that fires without an event
Pact emails the reporter and assignee once when an issue goes at-risk and once when it breaches. Two design decisions sit behind that sentence.
The first: the email checkbox is off by default on a new policy. A policy you have just written is a guess about thresholds, and a sweep runs every five minutes across every configured project — so switching alerting on is a deliberate act after the numbers look right, not something that happens the moment you click Save. Anyone who has watched a well-meaning configuration change generate several hundred emails will recognise why.
The second: that five-minute sweep exists to catch the breach that generates no event. If alerting is driven only by status changes and edits, the most dangerous issue on the board — the one nobody has touched for a week — silently sails past its deadline without notifying anybody. Pact re-checks on a timer precisely so untouched issues are still caught.
Warnings for policies that break silently
Three configuration mistakes produce no error and no obviously wrong behaviour, which is what makes them expensive. A status ticked as both running and stopping the clock: the stop wins, so time spent there is never counted, and your numbers are quietly too good. A policy with no stop status at all: nothing can ever settle, so every matching issue eventually breaches and the report becomes noise. Two policies sharing a name: the report and the alert emails become ambiguous.
Pact checks for all three after you save and lists them on the settings page. They are warnings rather than blockers — the policy still saves — but they turn up when you are looking at the policy, not three weeks later when someone questions the report.
Runs on Atlassian
Pact carries Atlassian’s Runs on Atlassian badge: it runs and stores its configuration entirely inside your own Atlassian cloud, with no external servers. Its alerts go through Jira’s own in-tenant notification system rather than an external mail provider, and it has no Slack integration and no outbound webhooks — deliberately, since either would send data outside Atlassian and forfeit the badge.
Checked on the Marketplace in August 2026, Time to SLA’s listing does not carry that badge. That is a statement about where processing happens, and nothing more. It is not an accusation about what Appfire does with data — plenty of excellent apps are hosted by their vendor, and the absence of the badge does not by itself tell you an app sends data anywhere. Verify it yourself on either listing if it matters to your security review.
Worth keeping in proportion: roughly a third of the Marketplace carries the Runs on Atlassian badge. It is hygiene that helps an app pass an enterprise filter, not a reason on its own to choose one product over another.
Price, which here is a genuine difference
Usually price is the weakest argument in a comparison like this. In this particular pairing it is not: the gap is between a third and two-thirds at every tier we measured. The table is in section 05.
Where Time to SLA is the better fit
Written plainly, because a comparison page that only flatters its own product is worth nothing to you.
- Track record. 236 reviews at 4.80 stars and thousands of teams running it in production. Pact has none of that yet, and “new” is a legitimate reason to say no.
- Cloud Fortified. Time to SLA holds Atlassian’s Cloud Fortified status, which covers operational maturity — reliability commitments, incident management, a bug bounty. Hullara does not hold it. If procurement asks, that is a genuine gap on our side, and it is one that takes months of operating history to close rather than a feature we can ship.
- A vendor with a support organisation. Appfire is a large publisher with staffed support. Hullara is small. For some buyers that is the whole decision.
- Breadth of features. Time to SLA has been developed for years and its configuration, reporting and search surface is considerably wider than Pact’s. We have deliberately not enumerated its feature list here, because we have not audited it and would rather say nothing than describe a competitor’s product inaccurately — read its listing.
- Jira Service Management alongside Jira Software. If you run both and want one SLA tool across them, that is not what Pact is built for. Pact exists specifically to serve Jira Software teams who are not on JSM.
- Reporting depth. Pact’s compliance report scans up to the 300 most recent issues in a project. That is sized for a team’s regular review, not for a full-history audit of a very large project.
Pricing
Both are sold through Atlassian with per-user monthly pricing, and both are free for sites of 10 users or fewer. Figures below were read from the Marketplace pricing API in August 2026 — check current prices before you buy, because they change.
On a 250-user site that is a difference of a little over two hundred dollars a month. Whether that matters depends entirely on your situation — for a team that already trusts Time to SLA and depends on its feature set, it plainly should not be the deciding factor. For a team choosing an SLA tool for the first time, it is real money.
What is free in Pact is unusual, and worth checking against your needs. The issue panel, the full policy configuration, and the at-risk and breach emails are free on every project at any team size — including sites far above ten users. The paid surface is the compliance report, the breached-issue drill-down and the two CSV exports. So the alerting, which is the reason most teams adopt an SLA tool at all, sits in the free tier.
Evaluating both without committing to either
You do not have to choose in order to compare. Both apps read the same Jira change history and neither writes to your issues, so running them side by side for a fortnight changes nothing about your data or your workflows.
- Install Pact and open any issue via Apps → SLA. The default SLA is already there — that is the zero-configuration claim, and it either holds on your workflow or it does not.
- In Project settings → SLA, adjust the starter policy to a target you actually promise. Save, and check whether the policy warnings flag anything — they often catch a status that both runs and stops the clock.
- Leave email off for the first few days. Watch the panel on real issues and confirm the states match your intuition before anything is sent to anybody.
- Compare the same period in both tools. Expect per-status elapsed times to agree, since both replay the same changelog, and expect headline compliance percentages to differ if one counts in-flight work as a miss and the other does not. Pact’s Met % is Met ÷ (Met + Breached), so unfinished work is excluded.
- Keep whichever you prefer and uninstall the other at a billing boundary. Nothing of yours left your tenant through Pact either way.
Questions
Also worth reading: Pact compared with SLA Time and Report · SLAs on Jira Software without JSM · the Pact user guide.