Service Level Agreement
Last updated: May 19, 2026
This Service Level Agreement ("SLA") sets out the availability and support commitments that DevOps Team ("we", "us") provides to customers ("Customer", "you") for paid services and paid apps published by DevOps Team, including those distributed through the Atlassian Marketplace. This SLA forms part of the agreement between you and DevOps Team. Where any term defined here conflicts with a separate signed agreement, the signed agreement controls.
1. Definitions
- Service — the paid software-as-a-service offerings, hosted apps, and integrations operated by DevOps Team to which you have a current paid subscription, including Atlassian Marketplace apps for which you hold a valid commercial license.
- Availability — the percentage of time within a calendar month during which the Service is operational and able to process requests, excluding the events listed in Section 6.
- Downtime — a period during which the Service is unavailable to a Customer that has correctly configured and is authenticating in line with the published documentation, excluding the events in Section 6.
- Incident — an unplanned event that causes Downtime or materially degrades the Service.
- Business Hours — Monday to Friday, 09:00 to 18:00 Central European Time (CET / CEST), excluding public holidays observed in Romania.
- Maintenance Window — a scheduled period during which the Service may be partially or fully unavailable for planned work, announced in advance per Section 5.
- Service Credit — a percentage of the Customer's monthly subscription fee for the affected Service that is credited toward a future invoice when the Availability target is not met.
2. Service Availability
2.1 Target
We commit to a monthly Availability of 99.9% for production instances of the Service.
2.2 Measurement
Availability is measured per calendar month, in minutes, using the formula:
Availability % = (Total minutes in month − Downtime minutes) / Total minutes in month × 100
Downtime is determined from our own monitoring systems and from substantiated Incident reports from Customers. Time spent within a Maintenance Window or otherwise within the exclusions in Section 6 does not count as Downtime.
2.3 Service Credits
If Availability in a given calendar month falls below the target, the affected Customer is eligible for a Service Credit calculated against the monthly fee for the affected Service:
| Monthly Availability | Service Credit |
|---|---|
| Less than 99.9% and at least 99.0% | 10% |
| Less than 99.0% and at least 95.0% | 25% |
| Less than 95.0% | 50% |
Service Credits are the Customer's sole and exclusive remedy for any failure to meet the Availability target. Credits are issued against future invoices and are not redeemable for cash.
3. Support Response Times
3.1 Severity classification
Each support request is classified into one of three severity levels. The Customer proposes the severity on submission; DevOps Team confirms or reclassifies based on the actual impact described.
| Severity | Definition |
|---|---|
| P1 — Critical | The Service is unavailable in production, or a critical function is completely non-operational, and no reasonable workaround exists. |
| P2 — High | A significant feature is impaired or producing incorrect results for a meaningful share of users, but a partial workaround exists or production work can continue with degraded capability. |
| P3 — Normal | Minor functional issues, cosmetic defects, configuration questions, feature requests, or documentation gaps that do not block production use. |
3.2 Response times
"Response" means a substantive reply from a DevOps Team engineer acknowledging the issue and outlining the next step — not an auto-acknowledgement. Times are measured from when the support request is received via an approved channel (Section 3.3):
| Severity | Target initial response | Coverage window |
|---|---|---|
| P1 — Critical | Within 4 hours | 24 / 7 / 365 |
| P2 — High | Within 1 Business Day | Business Hours |
| P3 — Normal | Within 3 Business Days | Business Hours |
Response time is a commitment to first substantive contact. Resolution time depends on the complexity of the issue and the Customer's responsiveness to requests for information; we commit to working continuously on P1 Incidents until restoration of Service or a documented workaround.
3.3 Approved support channels
- Email: [email protected]
- Live chat: chat.devopsteam.io (Business Hours)
- Marketplace ticket system for apps distributed via a marketplace, where the platform provides one (e.g. Atlassian's Support portal for paid Marketplace apps)
Support requests sent through social media, public forums, or to individual employees do not start the response-time clock.
4. Status Communication
For ongoing Incidents we provide updates through the approved support channel on which the Incident was reported. For P1 Incidents affecting multiple Customers, we issue updates at least every 60 minutes until the Incident is resolved. A post-incident summary is available on request for any P1 Incident lasting longer than two hours.
5. Maintenance Windows
5.1 Scheduled maintenance
Scheduled maintenance is performed outside Business Hours where possible. We aim to keep Service-affecting scheduled maintenance under two hours per month per Service. Notice of at least 72 hours is provided by email to the Customer's billing contact and, where available, posted in the relevant in-app or marketplace channel.
5.2 Emergency maintenance
From time to time we may need to perform unscheduled work to address a security or stability risk that, if left, would lead to a larger Incident. We will give as much notice as the circumstances reasonably permit. Emergency maintenance does not count toward Downtime.
6. Exclusions
The Availability target does not apply to, and the following do not count as Downtime:
- Scheduled or emergency Maintenance Windows as defined in Section 5.
- Force majeure: events outside our reasonable control, including natural disasters, war, government action, internet backbone failures, and large-scale outages of upstream cloud or registrar providers.
- Customer-caused issues, including misconfiguration, modification of the Service outside published interfaces, exceeding plan limits, expired credentials, or actions of the Customer's users.
- Beta, preview, alpha, experimental, or otherwise pre-release features explicitly labelled as such in our documentation.
- Failures or degradation of third-party services on which the Service depends (for example, the marketplace platform itself, the Customer's identity provider, or third-party APIs the Customer has chosen to integrate), to the extent the failure is attributable to that third party.
- Suspension of the Service for non-payment, breach of acceptable use, or where required by applicable law or by an order of a competent authority.
- Failures of network connectivity or hardware on the Customer's side of the connection.
7. Claiming Service Credits
To claim a Service Credit, the Customer must:
- Submit the claim by email to [email protected] within 30 calendar days after the end of the calendar month in which the Availability target was missed.
- Include the affected Service, the dates and approximate times of the relevant Downtime, and any reference numbers from prior support tickets.
We review claims against our monitoring and ticket records and respond with a determination within 15 Business Days. Approved credits are applied to the next invoice for the affected Service. Service Credits do not accumulate beyond a single month's fee for the affected Service.
8. Suspension and Termination
This SLA does not entitle a Customer to terminate a subscription for an SLA breach in isolation. Termination rights are governed by the underlying agreement or the terms of the relevant marketplace. Repeated material failure to meet the Availability target across three or more consecutive calendar months, however, entitles the Customer to terminate the affected Service without penalty and to receive a pro-rated refund of any prepaid, unused fees.
9. Changes to this SLA
We may update this SLA from time to time. Where a change reduces the Availability target, weakens a response-time commitment, or otherwise materially reduces the Customer's rights, we will give at least 30 days' advance notice by email to the billing contact. Continued use of the Service after the effective date of a change constitutes acceptance of the updated SLA. The "Last updated" date at the top of this page reflects when the SLA was last revised.
10. Contact
Questions about this SLA, or to claim a Service Credit:
DevOps Team
Email: [email protected]
Live chat: chat.devopsteam.io
Phone: +40 752-311-893 (EMEA) / +1 415-830-9077 (US)