amber.systems service level and support schedule

Version 2026-08-18 - last updated 18 August 2026

1. When this schedule applies

1.1 This schedule applies only where an Order Form expressly incorporates it and identifies one or more covered Services.

1.2 The Order Form must state any numerical uptime commitment, support hours, response target, recovery objective or service credit. If it does not, amber.systems will provide the Service with reasonable care and skill but no numerical service level or service credit applies.

1.3 A Service Schedule or Order Form may contain more specific service levels and takes precedence over this schedule for those matters.

2. Definitions

• Availability means the ability of an authorised user to access the material core functionality of a covered Service at its published service edge.
• Availability Commitment means the monthly percentage expressly stated in the Order Form.
• Business Hours means 09:00 to 17:00 UK local time on Business Days, unless the Order Form states otherwise.
• Downtime means a period in which the covered Service is unavailable, excluding Excluded Downtime.
• Emergency Maintenance means urgent work reasonably necessary to address a security vulnerability, incident, legal requirement, data-integrity risk or imminent material failure.
• Excluded Downtime has the meaning in section 5.
• Measurement Period means a calendar month unless the Order Form states otherwise.
• Scheduled Maintenance means planned maintenance notified in accordance with section 4.
• Service Credit means a credit calculated under section 8 where the Order Form expressly provides one.
• Support Request means a request submitted through an approved support channel by an authorised contact.

3. Availability measurement

3.1 Where an Availability Commitment applies, monthly Availability is calculated as:

(total minutes - Excluded Downtime minutes - Downtime minutes)
----------------------------------------------------------------- × 100
(total minutes - Excluded Downtime minutes)

3.2 Availability is measured using amber.systems monitoring and service records at the relevant service edge. The Customer may provide contrary evidence of a material measurement error.

3.3 A partial degradation counts as Downtime only where it prevents a material core function from being used by a substantial proportion of affected authorised users. A cosmetic issue, isolated request failure or failure of a non-core feature does not count unless the Order Form states otherwise.

3.4 Multi-component services may have separate Availability Commitments. The failure of one component does not automatically count as unavailability of another.

4. Maintenance

4.1 We may perform Scheduled Maintenance. Where it is reasonably likely to affect availability, we will normally give at least two Business Days’ notice through email, the console, a status page or another agreed channel.

4.2 We will use reasonable efforts to schedule disruptive maintenance outside the Customer’s stated critical period where that period is documented and compatible with operational needs.

4.3 Emergency Maintenance may be performed without advance notice. We will notify affected Customers as soon as reasonably practicable and explain the general reason, subject to security and confidentiality constraints.

5. Excluded Downtime

Downtime is excluded to the extent caused by:

• Scheduled Maintenance or Emergency Maintenance;
• the Customer’s systems, network, software, data, credentials, configuration, instructions or breach;
• a Third-Party Service selected or controlled directly by the Customer;
• an internet, telecommunications, DNS or routing failure outside systems we control;
• a force-majeure event;
• suspension permitted by the Contract;
• an attack or incident that could not reasonably have been prevented by the agreed controls;
• a beta, preview, trial or free feature;
• a Customer-requested test, change, migration or maintenance activity; or
• a service limitation or quota expressly documented and exceeded by the Customer.

An upstream provider failure is not automatically excluded where we selected and manage that provider as part of the Service. Its treatment depends on the architecture, the Order Form and whether we used reasonable care and available mitigation.

6. Support priorities

Unless the Order Form defines different levels, Support Requests are classified as follows:

Priority	Description
P1 - Critical	A production Service is wholly unavailable, there is a confirmed material security incident, or critical data integrity is at immediate risk, with no reasonable workaround.
P2 - High	A material production function is seriously degraded or unavailable to many users, but the Service remains partly usable or a temporary workaround exists.
P3 - Normal	A non-critical defect, degraded feature, configuration issue or request materially affects use but does not prevent core operation.
P4 - Low	A question, cosmetic issue, documentation request, feature request or planned change.

We may change a priority where the evidence and impact do not match the submitted classification. We will explain a material reclassification.

7. Response and resolution targets

7.1 The Order Form may specify:

• support channels and hours;
• initial-response targets;
• update intervals;
• restoration or workaround targets;
• resolution targets; and
• escalation contacts.

7.2 An initial response means a substantive acknowledgement that assigns the case and begins triage. A generic automated receipt confirmation does not by itself count as the initial response. An initial response is not a resolution.

7.3 Unless expressly described as a commitment, a response, restoration or resolution time is a target. Resolution depends on reproducibility, Customer cooperation, dependencies, risk and whether a third-party fix is required.

7.4 A target pauses while we reasonably await Customer information, access, approval or testing.

7.5 The Customer must submit P1 and P2 issues through the channel specified for urgent support and provide current contact details, impact, start time and available evidence.

8. Service Credits

8.1 Service Credits apply only if the Order Form states an Availability Commitment and states that Service Credits apply.

8.2 Unless the Order Form states another formula, a credit is calculated as follows:

Monthly Availability	Credit against the affected monthly recurring Fee
At or above the Availability Commitment	0%
Below the commitment by up to 0.5 percentage points	5%
Below the commitment by more than 0.5 and up to 2 percentage points	10%
Below the commitment by more than 2 percentage points	25%

8.3 The maximum Service Credit for a Service in a Measurement Period is 25% of its affected monthly recurring Fee.

8.4 A credit applies to a future invoice and has no cash value, except where the Contract ends before it can reasonably be applied.

8.5 The Customer must request a credit within 30 days after the end of the affected Measurement Period and provide reasonable supporting detail. We may apply a clear credit automatically.

8.6 Service Credits are the sole monetary remedy for failure to meet the numerical Availability Commitment itself. They do not exclude a remedy for a separate breach, confidentiality failure, data-protection breach, fraud or liability that cannot lawfully be limited.

8.7 No credit is due where the Customer is materially overdue in payment or the Downtime is excluded under section 5.

8.8 If a covered Service fails to meet its Availability Commitment in three Measurement Periods within a rolling six-month period, the Customer may terminate that affected Service on written notice given within 30 days after the third failure, without an early-termination charge. This does not waive Fees for Services already supplied or non-cancellable third-party commitments.

9. Security and incident communications

9.1 Security incidents affecting Customer Personal Data are handled under the DPA, not solely through support targets.

9.2 We may restrict technical detail in a public status update where disclosure would increase risk, expose another customer or prejudice an investigation. Affected Customers will receive appropriate direct information under the Contract.

10. Customer obligations

The Customer must:

• maintain accurate support and escalation contacts;
• provide enough detail to reproduce and assess an issue;
• make authorised personnel available for urgent incidents;
• apply reasonable workarounds and updates;
• maintain Customer-controlled backups and dependencies unless expressly included; and
• avoid submitting duplicate or misleading urgent cases.

11. Changes

A numerical commitment applying to a fixed term changes only by written agreement. Operational procedures and contact channels may change under the General Terms, provided the change does not materially reduce an agreed commitment.