This Support Policy, including any attachments or other terms referenced herein (together, the "Policy"), is part of and subject to the framework licensing agreement applicable to the Platform (the “Agreement”). The Policy may be regularly updated by Kubeark. References to websites hereunder include references to successor websites.Defined Terms. Capitalized terms have the meaning prescribed in the Agreement, unless otherwise defined hereunder.
- “Business Day” means a daily 8-hour period during the working hours and working days in the country from which Kubeark is providing support (currently Romania).
- “Customer” means an entity executing an Agreement with Kubeark.
- “Documentation” means the official documentation for the Platform, as made available on https://docs.kubeark.com/.
- “Downtime” means the period of time consisting of the number of unavailable minutes in a calendar month, caused by Kubeark’s actions or omissions. A minute is unavailable if all continuous requests initiated by a user for Platform usage to perform operations throughout the minute do not return a response or return a response indicating a failed operation. Downtime does not include the unavailability of the Platform due to Support Exclusions in the Policy.
- “Fees” means the fees payable to Kubeark under the Agreement, as set in the applicable Order.
- “First Response Time” is the duration between the moment a Customer submits a Ticket and the time Kubeark support team first acknowledges and responds to the Ticket, regardless of the Incident's final resolution time.
- “Incident” means the failure of the Platform to function as set forth in the applicable Documentation, or an event resulting in Downtime, and excludes any request that does not meet the criteria for an Incident, including requests limited to information or advice on Platform use instructions, activation, and licensing.
- “Order” means the formal document agreed by the Parties specifying the services ordered and the Fees payable, irrespective of whether it contains a reference to this Agreement or not and excluding any terms and conditions added unilaterally by Customer.
- “Platform” means each and any Kubeark platform components, including any software or on-premise components provided therein, any development kits, protection mechanisms, plugins, connectors, extensions, scripts or any other software made available to Customer, including during support or pursuant to warranty obligations, all new releases, versions, modifications, updates, patches, improvements, enhancements, or similar derived works thereto, any complete or partial copies or derived works, or any Intellectual Property related to all of the foregoing, but excluding third-party services or software.
- “Scheduled Downtime” means the period of time reserved by Kubeark to apply fixes and updates to its Platform as part of regular maintenance. Scheduled Downtime is communicated to the Customer through any channels.
- “Ticket” means the formal means used by Kubeark to receive Incident notices from Costumer via the ticket platform available at (or successor website) https://kubeark.com/support-ticket.
- “Uptime” means the level of availability of the Platform maintained by Kubeark for the Customer in cloud, represented as a percentage, consisting of the number of available minutes (defined as total minutes in a calendar month including Scheduled Downtime) in a calendar month minus any Downtime, divided by the number of available minutes in a calendar month, and multiplied by 100.
- Support Standards
2.1. Support Schedule. Scope. Except as otherwise provided in this Policy or previously agreed upon in writing with the Costumer, Kubeark will provide support solely on Business Days. Kubeark will only provide support for the Platform during the applicable License Term, and subject to receiving the corresponding Fees. At its sole discretion, Kubeark may provide support for other products, services or software released by Kubeark, or for certain third-party products.
2.2. First Line Support. The Customer will perform first line support by investigating any connectivity, access permission, database provisioning, or security issues related to its systems, networks, or applications interacting with the Platform, before submitting a Ticket.
2.3. Support Plans. Kubeark provides support in accordance with the Documentation and the response times listed below:
First Response Time
Normal - is a low and medium-to-low impact error within the Platform that involves partial and/or non-critical loss of functionality of the Platform (for testing, training, or development, as well as production purposes)
1 business day
High - is an error within the Platform that renders the Platform to function in a reduced capacity for production purposes, such as a problem that is causing significant impact to portions of the Customer’s business operations and productivity, or where the Platform is exposed to potential loss or interruption of service.
Urgent - is a major production error within the Platform that severely impacts the Customer’s use of the Platform for production purposes, such as the loss of production data or where production systems are not functioning, and no workaround exists.
2.4. Fixes and Updates. If, in relation to an Incident, a permanent fix is not feasible, Kubeark may provide a workaround to restore the use of the Platform. Kubeark updates its Platform continuously and Customer must not restrict such updates. Based on the confirmed Priority Level, Kubeark will target the first response times noted in the support plan relevant for the Customer. Kubeark will make commercially reasonable efforts to respond to requests that do not meet the requirements to be an Incident but is not bound by the response times prescribed herein.
2.5. SLA. Kubeark will make commercially reasonable efforts to provide Customer with an Uptime of minimum 95% of the time during each calendar month. For the avoidance of any doubt Uptime applies solely to the Platform that is maintained by Kubeark in cloud and does not apply for deployments made by the Customer in their own environment, including on-premises or cloud or otherwise.
- Ticket Management and Cooperation
3.1. Customer agrees to: (i) perform first line support and ensure a problem exists before filing a Ticket, (ii) cooperate and communicate in a timely manner with Kubeark, (iii) provide Kubeark with sufficient and accurate information related to the Incident, (iv) assign contact persons with the necessary technical and communication skills to collaborate with Kubeark, (v) make reasonable attempts to replicate, or to assist Kubeark in replicating the Incident under the circumstances in place at the moment of Ticket submission, including by conducting diagnostic or troubleshooting activities, and (vi) resolve the Incident as indicated by Kubeark.
3.2. Incidents must be submitted exclusively via Tickets, in writing and in the English language. Kubeark will be under no obligation to reply to Incidents received in any other manner. A valid Ticket must contain the following:
- Customer information: name, contact information, and Order number of the Customer;
- Description: (a) a detailed description of the reported issue , including any error messages and other relevant information, (b) initial Costumer attempts to solve the Incident and (c) reasonable approximation of date and hour when the issue/Downtime occurred;
- Reproduction steps: the steps necessary to reproduce the issue;
- Platform version: the version number of the Platform that is experiencing the issue;
- Priority Level: the Priority Level perceived by the Customer, and a reasonable explanation of the assessment
- Confirmation of First line support: confirmation from Customer that it investigated any connectivity, access permission, database provisioning, or security issues related to its systems, networks, or applications interacting with the Platform and it did not solve the reported issue.
- Supporting evidence: if relevant, any supporting documentation or files that may be necessary to diagnose or resolve the issue.
3.3. Kubeark may respond to a Ticket in writing, or with the Customer's consent, by video conference or remote connection. Kubeark will evaluate the Priority Level as indicated by the Customer and, at its sole discretion, confirm or recategorize it.
3.4. A Ticket is considered closed when a final solution to the relevant Incident is communicated by Kubeark. The final solution includes, but is not limited to, a hotfix, patch, temporary workaround, future upgrade, permanent fix, or any other solution that Kubeark may reasonably consider to be final.
3.5. If Customer believes, in good faith, that an High or Urgent Incident was not addressed by Kubeark in accordance with this Policy, Customer may escalate by sending an e-mail in English to firstname.lastname@example.org within maximum 30 (thirty) days after receiving a final response to the relevant Ticket. The email must contain at least the following information: Ticket date, reason for escalation, and proposed solution. Kubeark will do commercially reasonable efforts to respond to escalation emails in a reasonable timeframe, but it will not be bound by the Response Times set out herein.
- Support Exclusions
Kubeark has no obligation to provide support for, and the Uptime does not apply in the following cases:
- Platform made available (i) for free, (ii) for trial, unless expressly stated otherwise in the applicable agreement, or (iii) as "early access", "private preview", "public preview", "beta", "experimental" or under a similar designation, or (iv) as specifically excluded in the Documentation;
- the Platform being accessed, used, configured or modified in breach of the Agreement (including Acceptable Use), this Policy, or the Documentation (including Prerequisites);
- the Platform not being updated by Customer in accordance with Kubeark instructions or best practices, if in the update Kubeark resolved the Incident for which the Customer requests support;
- the Platform being used with other products or software that are not officially supported, are out of support, or have been deprecated;
- the Ticket does not contain the necessary information for it to be considered valid, as per the Policy;
- Customer’s negligence or willful misconduct, or Customer’s failure to cooperate for the resolution of a Ticket;
- use of Platform with hardware or software not developed by Kubeark which does not meet the software and/or hardware requirements of the Platform as expressly stated in the Documentation;
- Customer’s failure to adhere to any required configurations, or to follow relevant security or acceptable use policies or practices;
- Scheduled Downtime;
- emergency Platform updates or fixes, even if not priorly scheduled, announced or noticed to Costumer;
- any customized deliverables created by Kubeark, its partners or third parties at Customer’s request;
- force majeure events or other factors outside Kubeark’s reasonable control (e.g., acts of God, natural disaster, lightning, fire, war, acts of terrorism, riots, terrorism, civil disorders, government action, network or Internet failure, connectivity disruptions, failure of Customer or any third party owned software, device, technology or infrastructures);
- features excluded from Uptime, as designated in the applicable Documentation;
- faulty input, instructions, or arguments (for example, requests to access files that do not exist) or Customer’s attempts to perform operations that exceed the Platform’s prescribed functionalities.
- at the time when the Downtime has occurred, Customer has outstanding invoices or current disputes regarding the payment of the Fees due to Kubeark or Platform license reseller.
Without prejudice to any limitation in the Agreement with respect to the use of personal data, Kubeark will process any personal data shared by the Customer for the purposes hereunder in accordance with the data processing agreement available on https://kubeark.com/terms. Notwithstanding, Customer has full control over the information shared for support purposes and is hereby recommended to limit the disclosure of personal data to the maximum extent possible.