Develocity Support Policy – 20220508

Last Updated: May 8, 2022

This Develocity Support Policy (as updated from time to time, the “Support Policy”) is attached to and incorporated in that certain Develocity Software License Agreement (the “Agreement”). Unless otherwise defined in the Support Policy, capitalized terms shall have the meanings attributed to them in the Agreement. Support and Maintenance are provided for the most recent Major or Patch Release of the Software. 

Software Maintenance and Technical Support Response Times for Errors: Gradle shall meet the response times listed below:

 

Hours of Operation 12 hours/day, 6:00 am – 6:00 pm London time 

5 days/week (Monday – Friday), excluding Good Friday, Easter Monday, Christmas (December 25th and 26th), New Year’s Eve (December 31st) and New Year’s Day (January 1st) (“Business Days”).
Support Language English
Support Access Method Web via Zendesk Support Platform
Support Response Method Web via Zendesk Support Platform
Number of Support Requests Unlimited

 

Service Level Objectives (SLO) Matrix
Error Severity Level Initial Response Target Update Frequency Workaround Target Resolution Target
Severity 1 Within 4 hours* Daily on Business Days or Customer initiated 1 Business Day Next Patch Release
Severity 2 Within 4 hours* Every 2 Business Days or Customer Initiated 5 Business Days Future Patch Release
Severity 3 By close of next Business Day* N/A Determined on a case-by-case basis Future Major Release, Patch Release or at the discretion of the Company
Severity 4 By close of next Business Day* N/A Determined on a case-by-case basis Future Major Release, Patch Release or at the discretion of the Company

* Support requests received less than four (4) hours prior the close of business (6:00pm London time) or outside Gradle’s hours of operation shall be deemed delivered at 6:00 am (London time) the following Business Day. 

SERVICE LEVEL COMMITMENTS

Gradle will expend commercially reasonable efforts to provide an Error Correction (as defined below) designed to resolve or bypass a reported Error per the above Service Level Objectives Matrix. Gradle, in its reasonable discretion, shall determine the severity level of Errors (as defined below).

1. “Error” means a failure of the Software to conform to the specifications set forth in the Documentation resulting in the inability to use the Software or a material restriction in the use of the Software. Errors are classed Severity 1, 2, 3 or 4, as follows:

Severity 1: Critical Business Impact – All Productive Activity Stopped

Customer is unable to use the Software in a material fashion or reasonably continue work using the Software in a production environment.

Severity 2: Major Business Impact ‐ Major Feature Failure or Performance Degradation

Critical Software components are not working properly while other areas of the Software are not impacted. The affected Software functionality has created a significant negative impact on Customer’s productivity or Customer’s service level. Severity 2 Errors include installation errors.

Severity 3: Minor Business Impact ‐ Minor Feature Failure

Critical software components are not working properly, however, an alternative solution is available. The following also qualify as Severity 3 Errors:

  • A non‐essential Software feature is unavailable with no alternative solution. 
  • Software behavior yields minimal loss of operational functionality or implementation resources.

 Severity 4: Minimal Business Impact – General Questions

The following qualify as Severity 4 Errors:

  • Software information requests 
  • Software enhancement requests 
  • Clarifications or questions regarding the Documentation 


2. “Error Correction” means either a Software modification or addition that, when made or added to the Software, corrects the Error, or a procedure or routine that, when observed in the regular operation of the Software, eliminates the practical adverse effect of the Error on the end user. Error Corrections are delivered to Customer via Resolutions and Workarounds.

The Service Level Objectives (“SLOs”) stated in the Service Level Objectives Matrix above are targets and do not include or account for time waiting for additional information from the Customer or other delays outside of Gradle’s reasonable control. The response times provided above are subject to Gradle’s hours of operation. The SLOs assume that the Customer has fulfilled all Customer Responsibilities described in this document and Gradle’s technical support personnel (“Technical Support”) have received all the requested technical information reasonably required to resolve the issue.

Service Level Objective (SLO) Definitions:

Customer Responsibilities

Customer Responsibilities include the submission of a complete and accurate support ticket through Zendesk as well as prompt and complete responses to any follow up inquiries from Technical Support requesting logs, files, or any additional information in connection with any support ticket.

Initial Response

Initial Response means the initial contact through the Zendesk support platform by a Technical Support engineer to gather additional information about a case, collect diagnostics, suggest workarounds, obtain reproduction data and/or gather configuration information.

Resolution

Resolution means a solution to an Error that addresses the root cause of the reported Error and eliminates the practical adverse effect of the Error. Gradle will aim to provide Resolutions per the Resolution Targets set forth in the Service Level Objectives Matrix. Resolutions will be provided through Patch Releases or Major Releases, as set forth in the Service Level Objectives Matrix.

Resolution Target

Resolution Target means the target Software release intended to provide a Resolution for the reported Error.

Major Release

Major Release means an enhancement release that may contain both corrections for non‐conforming Software behavior and new functionality. Gradle, in its sole discretion, shall determine which enhancement suggestions to fulfill in each Major Release. A “Major Release” is identified by the first and second numbers separated by the first decimal point in the release number sequence (i.e. 2017.1).

Patch Release

Patch Release means a Software release containing corrections for non‐conforming Software behavior. Patch Releases may or may not contain new functionality. A Patch Release is identified by the release number after the right‐most decimal point in the release number sequence (i.e. 2017.1.1). All releases, including Major Releases, do not include modules or add‐on products that the Customer has not licensed from Gradle.

Update Frequency

Update Frequency means the frequency with which Technical Support provides information regarding the case status to the Customer. Periodicity may be extended by mutual agreement between Customer and Technical Support.

Workaround

A Workaround is a solution that provides relief from the non‐conforming Software behavior. A Workaround may take the form of an alternate usage, a system configuration change, a patch and/or design approach, or information in the case of an information request.

Workaround Target

Workaround Target means the target time period in which Gradle intends to provide a Workaround for the reported Error.