Service Level Agreement

1. Scope

This SLA applies to platforms we built ourselves under a Project Delivery engagement and subsequently operate. For existing systems we did not build, it applies only after an Architecture Sprint in which we review the architecture, operational readiness and risks. The reason is simple: we do not commit to reaction times for systems we do not know.

The individual contract prevails. Where its provisions differ from this SLA, those provisions take precedence.

2. Definitions

• Reaction time: The period between receipt of an incident report through the agreed reporting channel and a qualified response from an engineer who takes up the work. Reaction time is expressly not a commitment to a restoration time.
• Service hours: The hours during which incident reports are worked on and during which reaction times run.
• Incident: A deviation of the platform from its contractually agreed function that impairs operations.
• Availability: The share of a calendar month in which the platform is reachable through the agreed endpoints and performs its core function.

3. Service hours

Our service hours are Monday to Friday, 10:00 to 18:00 (CET/CEST), excluding public holidays at the registered seat of StackVera Core GmbH in Bavaria.

Automated monitoring runs continuously, around the clock. Alerts raised outside service hours are worked on at the start of the next service hours. On-call cover outside service hours is not part of this SLA and can be agreed separately.

Incident reports received outside service hours are deemed received at the start of the next service hours.

4. Severity classes and reaction times

We classify incidents at our reasonable discretion based on the reported impact and agree the classification with the client.

We work an incident until it is resolved or until a viable workaround is in place. The effort is charged against the included engineer days. Effort beyond that is billed at the agreed daily rate, after prior agreement with the client.

5. Availability

We commit to an availability of the operated platform of 99.5 % per calendar month. That corresponds to roughly 3 hours and 39 minutes of possible downtime per month. Measurement is taken by our monitoring at one-minute intervals.

The following do not count as downtime:

• announced maintenance windows under section 6;
• outages at infrastructure or third-party providers beyond our control, in particular cloud providers, network operators and external interfaces;
• incidents caused by changes the client or third parties engaged by the client made to the platform without our agreement;
• incidents resulting from outstanding client cooperation under section 8;
• force majeure and attacks that exceed the contractually agreed scope of protection.

6. Maintenance

We announce planned maintenance at least five working days in advance and carry it out outside service hours where possible. We may carry out security-related updates without notice where a delay would put the platform or the client data at risk. In that case we inform the client without delay.

7. Included services

The monthly fee covers:

• monitoring of availability, errors and capacity, including upkeep of the alerting;
• incident response within service hours according to the reaction times in section 4;
• patching as well as dependency and infrastructure updates;
• a monthly health and cloud cost report with prioritised recommendations;
• two engineer days per calendar month for planned work or incident resolution.

Unused engineer days do not roll over and expire at the end of the month. Additional days are billed at the agreed daily rate once approved by the client.

Not included are, in particular, development of new features, migrations, on-call cover outside service hours, and third-party licence and infrastructure costs.

8. Client cooperation

So that we can meet the committed reaction times, the client undertakes to:

• name a technical contact and a deputy;
• provide us with the access and permissions required for operations on a lasting basis;
• report incidents through the agreed reporting channel, describing impact, timing and reproducibility;
• agree changes to the platform with us in advance;
• assist in isolating an incident within service hours.

For as long as required cooperation is outstanding, the reaction time is suspended.

9. Reporting channel and escalation

Incidents are reported exclusively through the support address named in the contract. Reports through other channels, such as personal email addresses or chat, do not trigger a reaction time.

Support address: support@stackvera.io

If a P1 incident is neither resolved nor mitigated by a viable workaround after eight hours within service hours, we escalate automatically to the management of StackVera Core GmbH. The client then receives a status report with the suspected cause and the next steps.

10. Consequences of non-compliance

This SLA does not provide for flat-rate service credits. Where we miss the committed reaction time for a P1 incident, we document the cause in the monthly report and agree measures with the client to prevent a recurrence.

If we miss the committed reaction time for P1 incidents three times within three consecutive calendar months, the client may terminate the operations contract with one month notice to the end of a month, notwithstanding the agreed minimum term. Further statutory rights of the client remain unaffected.

11. Changes to this SLA

We may adjust this SLA, for example to add new services. We will communicate changes that reduce the scope of services to the detriment of the client in text form at least 30 days before they take effect. If the client does not object within that period, the new version is deemed agreed. If the client objects, the previous version continues to apply until the end of the current contract period.

12. Questions about this SLA

We answer questions about this service level agreement at hello@stackvera.io.