Project Management Software Uptime and SLA: What Vendors Promise

What does 99.9% uptime actually mean in hours?

project management software uptime is a key topic in modern project management and teamwork. Uptime percentages are easier to judge once you convert them to time. The table below uses a 365-day year and a 30-day month, which is how most vendors calculate credits.

The jump from 99.9% to 99.99% cuts allowed downtime tenfold, and it usually doubles the price. For most teams, 99.9% is a reasonable target: it absorbs a bad deploy without turning into a monthly event. The problem is not the number. The problem is that a monthly window hides the shape of the outage. Eight hours of downtime spread over twelve incidents is a different operational reality from one eight-hour outage during quarter-end close.

Also notice the difference between “monthly uptime” and “annual uptime.” A vendor that misses 99.9% in one month but averages 99.95% for the year has still breached the monthly commitment. Read which period the contract measures, because it determines whether a single bad week triggers a credit.

What do vendors actually promise in 2026?

Vendors promise different things at different tiers, and the gap between marketing language and contractual language is wide. Here is what the public pricing and legal pages state as of November 2026.

Two patterns are worth internalizing. First, the SLA is a sales feature of the top tier. If you are on a $9-per-seat plan, you are usually relying on goodwill and a status page, not a contract. Second, the same company can offer different numbers on different products. Atlassian’s Premium tier commits to 99.9% and Enterprise to 99.95%, which means the upgrade decision includes a reliability decision.

> Important note: A public “99.9% uptime” badge is not the same as an SLA. An SLA names the measurement, the exclusions, the credit, and the claim process. If any of those are missing, you have a marketing claim.

What is excluded from the uptime calculation?

Almost everything that would make the number inconvenient. Atlassian’s published SLA is a useful reference because it is unusually explicit, and its exclusion list is typical of the category.

Scheduled maintenance. Routine and emergency maintenance windows are excluded, provided they follow the vendor’s maintenance policy. A vendor can therefore be unavailable for two hours on a Saturday and still report 100% monthly uptime.

Customer-side causes. Your network, your SSO configuration, your firewall, and your own integrations do not count against the vendor. Neither do force majeure events or problems with third-party products.

Specific features only. Atlassian defines “Covered Experiences” for each product — for Jira, that means viewing, creating, and editing issues and viewing boards. Coverage is browser-based only, so API calls, mobile apps, and integrations sit outside the commitment. If your workflows run through the API, the SLA may not cover the surface you actually depend on.

How downtime is measured. Atlassian counts a “downtime minute” only when more than 5% of requests to a covered experience fail in that minute. A minute where 4 in 100 requests fail is not downtime, even though four users saw an error. This threshold is standard practice, and it means small, constant error rates can persist without ever breaching the SLA.

Free, beta, and sandbox environments. Excluded in most agreements, including Atlassian’s.

Put these together and the effective promise is narrower than the headline: browser-based core actions, excluding maintenance and your own misconfiguration, measured at a 5% error threshold. That is still a commitment — just not “always available.”

How do service credits work, and what are they worth?

Credits are calculated as a percentage of the monthly fee for the affected product, and they are usually the only remedy. Atlassian’s schedule is a good benchmark: below 99.9% but at or above 99.0% earns 10% of monthly fees; below 99.0% but at or above 95.0% earns 25%; below 95.0% earns 50%. Enterprise plans start at 5% for missing 99.95%.

Run the numbers on a realistic contract. Suppose you pay $60,000 a year, or $5,000 a month.

Example 1: a 60-minute outage in a 30-day month. Total minutes are 43,200. Sixty minutes of downtime is 0.139%, so uptime is 99.861%. That falls in the 99.0–99.9% band, which earns a 10% credit: $500. One hour of lost access returns half a day of one developer’s fully loaded cost, assuming that developer costs $1,000 a day.

Example 2: a full business day outage. 1,440 minutes gives 96.67% uptime, which lands in the 95–99% band: a 25% credit, or $1,250. If your team of 40 loses a day of delivery at an average loaded cost of $400 per person, the internal cost is roughly $16,000. The credit covers 8% of it.

Example 3: three bad months. Suppose the vendor breaches in October, November, and December at the 10% level. You receive $1,500 across the quarter, and only if you file three separate claims within the claim window — Atlassian requires a ticket within 15 days after the end of each month.

That detail matters operationally: credits are not automatic. Someone has to notice the breach, gather evidence, and file a claim inside a short window, and most organizations never do.

The credit cap is another limit: Atlassian caps the aggregate credit at 100% of the monthly fee for the affected product, and credits apply to future invoices rather than cash. In other words, the remedy for a catastrophic month is a free month, not compensation for the business interruption.

How do you judge real reliability instead of the promise?

Read the incident history, not the badge. Every major vendor publishes a status page, and most keep a history of past incidents. That history is the closest thing to an audited track record you can get before signing.

Four things to check:

1. Incident frequency. Twelve incidents in ninety days is a pattern, regardless of the uptime percentage. Look for a cluster around releases or Monday mornings.
2. Duration and scope. A 15-minute global outage and a four-hour degradation affecting one region are different risks. Status pages usually say which.
3. Partial degradation. Many incidents never become downtime under the SLA definition because the error rate stays under 5%. Slow boards, broken search, and failed automations still cost your team time. Status history captures them; the SLA may not.
4. Communication quality. Did the vendor post updates every 30 minutes, or one vague message and a resolution six hours later? The second pattern predicts how your next outage will feel.

Add one external check: ask a reference customer on the same tier and region, “When was the last time the tool was unusable, and what happened?” Compare that answer to the status page. Independent monitoring services can supplement vendor-reported data; they are not authoritative, but they catch failures a vendor classifies as “degraded performance.”

What should your own continuity plan include?

Assume the tool will be unavailable during your most important week, and design for it. That is not pessimism; it is the same logic as backing up a laptop.

Keep a read-only copy of the critical path. Export the project plan, milestones, and owners weekly to a shared drive. A CSV is ugly and sufficient. If the tool is down on a deadline day, you can still run the meeting from the export.

Do not put the tool on the critical path of a demo. Screenshots, a recorded walkthrough, or a PDF status report remove the single point of failure from client-facing moments.

Test the export before you need it. Vendors differ in what they let you export: tasks and comments are standard, but custom fields, attachments, and automation history are not. Run a full export during the trial and open the files. A backup you have never restored is a hypothesis.

Know your recovery requirements. If you cannot tolerate four hours without the board, ask for recovery time and recovery point objectives, and check whether they are contractual. Most public SLAs cover availability, not disaster recovery.

Document the manual fallback. Who declares an incident? Where does the team go for status? Which tasks can wait? A one-page fallback plan turns an outage from an argument into a procedure.

What should you negotiate in the SLA?

If you are signing an enterprise agreement, the SLA is negotiable even when the vendor presents it as standard. Five clauses are worth pushing on.

Measurement scope. Ask for the API and mobile apps to be included in covered experiences, or at least for a separate API availability commitment. Integrations are how modern teams use these tools; excluding them excludes the risk you care about.

Credit percentages. Published schedules are modest. A larger credit — or a service-level termination right after repeated breaches — is often available at renewal, especially when you can show incident history.

Root cause reports. Ask for a written post-incident review within five business days for any breach. The report is often more valuable than the credit because it tells you whether the cause was a one-off or an architectural weakness.

Termination for cause. A right to exit without penalty after three breaches in a rolling twelve months changes the vendor’s incentives more than any credit percentage.

Data return. Confirm the export format, timeline, and cost at termination — an exit plan is part of reliability.

> Practical tip: Put the SLA review on the renewal calendar 90 days before the contract ends, alongside the incident log. Renewal is the only moment when you have leverage, and the log is the evidence.

Trade-offs: what you give up for a stronger SLA

Higher uptime commitments cost money, and the money does not always buy what you expect. Moving from a 99.9% tier to 99.95% often means a jump to enterprise pricing, annual prepay, a minimum seat count, and a security review. For a 25-person team, that can double the annual cost for four extra hours of allowed downtime.

There is also an operational trade-off. Teams chasing the highest possible uptime sometimes centralize everything in one “reliable” platform, which increases the blast radius of any outage. A slightly less reliable tool with a good export and a documented fallback can be safer than a highly available tool with no exit plan. And a strict SLA with a 5% error threshold and browser-only coverage can look better on paper than a looser promise that covers the API.

Common mistakes when reading an SLA

• Comparing headline percentages across vendors without checking which tier they apply to and what is excluded.
• Assuming credits are automatic. They usually require a claim within 15–30 days, with evidence.
• Treating a status page as marketing. The incident history is data; the green banner is not.
• Ignoring maintenance windows. A vendor with a weekly two-hour window has materially less availability than the percentage suggests.
• Forgetting the API. If your automations and integrations matter, a browser-only SLA covers the wrong surface.
• Skipping the export test. Reliability includes getting your data out, not just keeping the UI up.

Where does Doitify fit?

Doitify is our platform, so read this with that in mind. We are not going to quote an uptime figure here that you cannot verify in a contract; ask our team for the current SLA, status page, and data export terms before you sign, and compare them using the same checklist you would apply to any vendor.

What we can speak to is the continuity side. Doitify keeps tasks, sub-tasks, checklists, dependencies, milestones, documents, meeting notes, and reports in one workspace, with import and export so your plan is not trapped in a format you cannot read. For teams that currently stitch a board, a spreadsheet, and a document store together, fewer moving parts means fewer integration failures — though it does not remove the need for a fallback plan.

The honest trade-off: a smaller vendor may offer less published reliability history than an established enterprise suite. If your organization requires a financially backed 99.95% commitment with a long incident record, that requirement should lead the evaluation, and a smaller platform should be judged on whether it can meet it contractually rather than on feature fit alone.

Conclusion

The uptime number is the beginning of the question, not the answer. Convert it to hours, find which tier actually carries the commitment, read the exclusions, and calculate what a credit would return on your contract size. Then look at the incident history, because a vendor’s last ninety days predict its next ninety better than its marketing page.

For most teams the practical package is 99.9% on a plan with a real SLA, a weekly export of the critical path, a one-page fallback plan, and a renewal reminder. That survives an outage far better than an extra nine you paid for but never tested.

If this post on project management software uptime was helpful, you might also enjoy Resource Planning Software: What to Look For and How to Reduce Context Switching at Work (2026 Guide).