Service Level Agreement -
Frontline Identity by Flip (EU)
Last updated: 06.08.2026
1. Subject matter
1.1 The following provisions of this Service Level Agreement (the “SLA Frontline Identity”) specify the service quality and availability owed by the Provider under the contract agreed with the Customer for the provision of software as a service and for customisation and implementation (the “Main Agreement”) in respect of the Frontline Identity product. This SLA forms part of the Main Agreement. In the event of conflicts between the constituent parts of the contract, the order of precedence agreed in the Main Agreement applies (clause 18.1 of the Terms).
1.2 Frontline Identity comprises the authentication and identity services which provide login, token issuance, token renewal and session management for access to the Flip platform and to applications connected to Frontline Identity. This SLA is a standalone agreement; it applies in addition to the SLA for the Flip platform and does not replace it. Impairments of the software service which do not affect the Frontline Identity services do not give rise to claims under this SLA; in that respect the SLA for the Flip platform applies exclusively. Periods during which the Frontline Identity services cannot be used solely because of an incident affecting the Flip platform count as excluded downtime within the meaning of clause 3.5. Service credits are not granted twice under both SLAs.
1.3 Definitions. Capitalised terms not expressly defined in this SLA have the meaning assigned to them in the Main Agreement.
The following definitions apply in addition:
“Provider” and “Customer” are the contracting parties so designated in the Main Agreement;
“Frontline Identity” means the authentication and identity services described in clause 1.2;
“incident” means a failure to meet the agreed system availability or any other impairment of the Frontline Identity services which the Customer reports under clause 5;
“service hours” means the times specified in clause 5.4 during which the Provider handles incident reports;
“response time” means the period specified per priority in clause 5.7 within which the Provider begins to handle an incident;
“maintenance window” means the periods of planned maintenance determined in clause 3.5(a) and in the table “Maintenance windows by region”;
“service credits” means the liquidated damages under clause 7.
The terms “system availability”, “downtime” and “excluded downtime” are defined in clause 3.
1.4 Amendments to this SLA. The current version of this SLA is available at https://www.getflip.com/legal/sla-identity-uk/ (United Kingdom and other countries) and at https://www.getflip.com/legal/sla-identity-us/ (United States). For the term of the Main Agreement, the version of this SLA that became part of the contract at the time the contract was concluded applies. The Provider is entitled to develop and adapt this SLA. Amendments affecting the agreed service levels, the scope of services or the Customer’s obligations are not made unilaterally during the current contract period; they are announced to the Customer in text form in accordance with clause 17 of the Terms, and in any event with a lead time of at least six weeks, and take effect for the existing contract at the earliest from the next renewal date. Purely editorial amendments and amendments that do not disadvantage the Customer (in particular extensions of the scope of services or improvements to the service levels) may be made by the Provider, following prior announcement, with effect for the current contract period as well.
2. Reference system
2.1 All performance figures in this SLA relate to the quality owed by the Provider of the Frontline Identity authentication services at the handover point of the data network or service operated by the Provider. Impairments outside the Provider’s sphere of influence are disregarded. This concerns in particular the Customer’s IT systems, the general internet infrastructure, global cloud outages, internet domains administered by the cloud provider, and external identity providers used by the Customer (for example Microsoft Entra ID, Okta, Google Workspace) which the Customer integrates into its Frontline Identity setup.
2.2 This SLA applies exclusively to productive Frontline Identity environments. It does not apply to staging, sandbox or preview environments, to the admin console, to the synchronisation of user directories (for example SCIM provisioning), to email-based password reset flows, to the administration of organisations and user associations, or to features expressly designated as beta or early access.
3. System availability
3.1 The Provider offers use of the Frontline Identity authentication services with a system availability of 99.9% per calendar month. System availability is determined separately for each customer.
3.2 System availability is measured by the Provider to the minute along the actual authentication flows at the productive Frontline Identity services. Requests within the meaning of this clause are requests for login/authorisation, token issuance and token renewal.
A request is deemed to have failed where the Provider does not answer it within 5 seconds with the expected result (a valid token or valid response). Requests attributable to excluded downtime (clause 3.5), in particular requests with invalid credentials, abusive use, and errors caused by customer, integration or third-party systems (including external identity providers), are disregarded.
The service is unavailable in a calendar minute where requests in that minute fail repeatedly such that proper authentication is not possible. Isolated failed requests and calendar minutes without requests are disregarded. The service level indicators (SLIs) set out below are non-binding target values. They describe the intended quality of service, do not create a separate performance obligation and do not constitute an agreement as to quality; a failure to meet them does not in itself constitute an incident within the meaning of this SLA. Only the determination under paragraphs 1 to 3 of this clause is decisive for system availability and for service credits under clause 7.
3.3 The percentage for system availability is calculated as follows:
3.4 “Downtime” means the total number of calendar minutes in the month during which the service was unavailable under clause 3.2. Excluded downtime is not counted.
3.5 “Excluded downtime” means the total number of minutes in the month attributable to the following:
maintenance or other services agreed with the Customer which prevent access to Frontline Identity. The Provider will make commercially reasonable efforts to carry out regular planned maintenance outside normal operating hours in the Customer’s respective hosting region. The applicable maintenance windows are specified in the table “Maintenance windows by region” below. The maximum permitted interruption of the service is 2 hours per maintenance window, and the total duration of planned maintenance may not exceed 4 hours per calendar month;
unforeseen and urgently required unplanned maintenance, where such work could not have been avoided even with reasonable care and planning;
periods of unavailability due to factors outside the Provider’s control (for example force majeure, unforeseeable events, downtime for which third parties are responsible, or outages of the Customer’s external identity providers such as Microsoft Entra ID, Okta or Google Workspace);
downtime due to denial-of-service, malware or hacker attacks, provided that the Provider has taken reasonable protective measures and the attacks could not have been avoided even with reasonable care;
downtime due to the Customer’s specifications or instructions, due to unavailability of the Customer’s equipment or due to other interruptions caused by the Customer (for example failure to provide required cooperation);
downtime for the installation of urgently required security patches;
downtime due to software errors in customer or integration applications, or due to errors triggered by customer applications or data;
requests with invalid credentials, abusive use of the service, and breaches of the acceptable use terms;
downtime caused by outages of the general internet infrastructure (for example DNS problems or internet BGP routing) or by global cloud outages.
Maintenance windows by region
The following maintenance windows apply to customers hosted in the respective regions. All times refer to the applicable local summer or winter time.
Region | Planned maintenance windows |
Germany | Sunday: 00:00 – 23:59 CET National public holidays: 00:00 – 23:59 CET |
United States (Central) | Monday – Friday: 10 PM – 4 AM CT Saturday – Sunday: 12 AM – 11:59 PM CT National public holidays: 12 AM – 11:59 PM CT |
Australia (East) | Monday – Friday: 10 PM – 4 AM AET Saturday – Sunday: 12 AM – 11:59 PM AET National public holidays: 12 AM – 11:59 PM AET |
3.6 It is incumbent on the Customer to report impairments of the authentication services to the Provider. The Provider will endeavour to remedy impairments without undue delay. There is no claim to restoration of the usability of the Frontline Identity services where the agreed system availability is met.
3.7 Where the Provider does not make Frontline Identity available in accordance with the contract within the agreed system availability, the Customer is entitled to restoration of availability in accordance with this SLA and to service credits under clause 7.
4. Priorities
Where the Provider’s services do not meet the values set out in this SLA, the Provider shall, in the event of impairment of both system availability and service quality, first restore the data security of the authentication services, then the login and token functionality, and subsequently response times.
5. Incident reports, restoration of services
5.1 The Customer may report a failure to meet system availability, or an impairment of the Frontline Identity services, as an incident.
5.2 The Customer shall report incidents to be handled under this SLA via the following contact point:
Form: https://flipappsupport.zendesk.com/hc/en-gb/requests/new for contacts, stating the request priority and a detailed description of the incident.
Incident reports received are confirmed to the Customer in writing (by email or ticket). The persons authorised to report incidents and to take decisions regarding the Frontline Identity system are dealt with in detail in clause 6.2.
5.3 Accelerated procedure for critical incidents (P1/P2). Incident reports classified as P1 (critical) or P2 (high) under clause 5.7 are handled as a priority and passed directly to the Provider’s responsible technical standby team. Handling takes place around the clock and irrespective of service hours. Receipt of a P1 or P2 incident report is confirmed to the Customer without undue delay.
5.4 The Provider handles incidents and incident reports for Frontline Identity during the following service hours: 7 days a week, 24 hours a day, 365 days a year (24/7/365), for all priority levels.
5.5 The Customer shall report incidents to be handled under this SLA only through employees trained and authorised for that purpose. Where the Customer reports an incident, it shall provide the Provider with the description of the incident in accordance with clause 5.7 as far as possible (for example in the case of identity provider problems for which the Provider is not responsible, involving Microsoft Entra ID or comparable external services). When reporting the incident, the Customer shall state which persons are available to the Provider as contacts at the Customer for that incident and how they can be reached by telephone. Contacts shall be named in such a way that the Provider can always contact one of the named contacts directly for the duration of the incident.
5.6 The Customer can view the current status of the incident and the incident report at https://www.getflip.com/status/.
5.7 Incidents subject to the provisions of this SLA are classified as follows:
Priority | Classification | Description | Response time (R) |
I. | critical / urgent (P1) | Total outage of authentication; login, token issuance or token refresh are entirely unavailable for one or more customers; all or almost all end users of an affected customer are unable to log in. | R = 30 minutes |
II. | high (P2) | Substantial impairment of authentication; a material proportion of requests fails (server errors, no valid result, or response times exceeding 5 seconds), or individual authentication flows partly fail; a substantial proportion of end users is affected. | R = 60 minutes |
III. | normal (P3) | An individual, non-critical function of Frontline Identity is unavailable; use in accordance with the contract is only insignificantly restricted; core authentication (login, token issuance, token refresh) continues to work; a substantial proportion of end users is affected. | R = 4 hours |
IV. | low (P4) | Minor impairment; only individual end users are affected; no effect on system availability under clause 3.2. | R = 12 hours |
5.8 Where an incident reaches a higher priority level, the Customer shall notify the Provider without undue delay. Measurement of the response time begins as soon as the Customer’s incident report under clause 5.2 is received by the Provider. The assignment of an incident to an incident class is determined by whether the characteristics stated in the incident description are present. The Provider may reassign the priority at its reasonable discretion on the basis of the criteria in clause 5.7. In all other respects, the provisions of clause 4 apply.
5.9 Upon receipt of a proper incident report from the Customer, the Provider undertakes to begin the analysis and, where possible, the remedy of the incident within the response times specified at the latest. Work to remedy incidents is carried out within the Provider’s means and in compliance with its contractual obligations. The Provider will make all reasonable efforts to remedy incidents as quickly as possible. The agreement of response times does not give rise to a claim to remedy the incident within a particular time.
5.10 There is no incident to be remedied by the Provider in the case of impairments of data transmission outside the data network operated by the Provider (for example due to line failure or line disruption at third parties), in the case of an outage of the Customer’s external identity providers (for example Microsoft Entra ID or Okta), or in the case of use of the provided system capacities in breach of contract (for example through an excessive number of accesses by the Customer).
5.11 The handling of incidents not defined in clause 5.7 is governed by the Main Agreement.
6. Monitoring, contacts, assertion of claims
6.1 The Customer has access to the monthly system availability of the Frontline Identity services and is responsible for checking it at the following page: https://www.getflip.com/status/.
6.2 The Customer shall provide the Provider with up-to-date contact details (name, email, telephone) of the responsible contacts, or of those authorised to report incidents, to whom all communication in connection with this SLA is to be addressed (for example announcements of maintenance, delivery of requested SLA reports and communication in emergency situations). The Customer shall ensure that these contacts can be reached reliably and are sufficiently enabled, informed and authorised in line with the requirements of the Frontline Identity integration (for example the Customer’s internal and central IT standby team).
6.3 It is incumbent on the Customer to keep its integration with Frontline Identity up to date at all times, to use only the documented APIs and supported authentication flows, and to provide, at the Provider’s request, the diagnostic information required to analyse and remedy incidents.
6.4 The Customer is entitled to the rights under clause 7 only if it notifies the Provider of their assertion in writing without undue delay, and at the latest within two weeks of the occurrence of the incident giving rise to those rights.
6.5 Escalations outside the standard support process under clause 5.2 are made via the Provider’s responsible account team.
7. Payment obligation in the event of an incident (service credits)
7.1 The following provisions supplement the statutory warranty provisions without displacing them. The Customer is entitled at any time to assert the rights available to it on account of the unavailability of the systems, the failure to grant use of the software, and breaches of duty in performing the services under the Main Agreement. Where it asserts those rights, it may assert the following rights only to the extent that they go beyond them.
7.2 Where Frontline Identity does not achieve the contractually agreed system availability (clause 3) and the response times in a given calendar month, and such a failure is reported by the Customer and verified by the Provider in accordance with this SLA, the Customer is entitled (without prejudice to its rights under clause 7.1) to liquidated damages in the form of credited service credits in accordance with the table below. Service credits are calculated on the basis of the monthly fee for the affected Frontline Identity licences.
Monthly system availability | Service credit |
< 99.9% and ≥ 99.0% | 10% of the monthly Frontline Identity fee |
< 99.0% and ≥ 95.0% | 25% of the monthly Frontline Identity fee |
< 95.0% | 50% of the monthly Frontline Identity fee |
7.3 Service credits may be applied immediately, and at the latest within two months, to the invoice following the calendar month of the unavailability. Service credits may only be applied to invoices issued under the Main Agreement and cannot be paid out or redeemed against any other consideration. A reduction on account of unavailability is set off against service credits and vice versa (clause 13.2 of the Terms). The Customer’s rights under clause 7.1 and the termination rights under the Main Agreement remain unaffected.