Service level schedule

Measurable promises on power, cooling, network, GPU nodes and remote hands, attached to a colocation, whitespace or GPU agreement. Sets how availability is measured, the service credits for a miss, and the exit right for persistent failure.

For both sides · Updated Nov 2, 2026 · Example to adapt

Create a free account to download

An editable .docx with the fill-ins highlighted.

How this model works

How it works

The service level schedule attaches to the main agreement and turns “a reliable facility” into numbers: how much of each month power, cooling, network and GPU nodes must be available, how quickly you respond to a call, and how fast you tell the customer about a problem.
Availability is measured month by month for each service element. Planned maintenance you announced properly, and problems the customer caused, do not count against you.
If you miss a level, the customer gets a service credit: a discount on the next invoice, worked out from the monthly charges and capped. Credits are usually the customer’s main remedy for a miss. Repeated or very long failures give the customer the right to leave without paying out the rest of the term.

Good for

Any colocation, whitespace or GPU deal where the customer needs to show its own customers, auditors or insurers what it is buying.
A baseline for negotiations with wholesale and hyperscale buyers, who often bring their own service level terms.
New sites and new operators: writing the levels down forces you to check that your design, staffing and suppliers can actually deliver them.

How the money works

Credits are a percentage of the monthly recurring charges for the affected racks, circuits or nodes. Metered electricity is usually left out of the base because it is passed through at cost.
Caps vary widely, from a small share of the monthly charges to the full monthly charges for the affected services. A higher cap is a real cost to you, so price it in.
Higher service levels cost money to deliver. A 100% promise on dual-fed power only makes sense if each feed is truly independent and the customer loads them correctly.
Remote hands is usually sold as a number of included hours per month, with an hourly rate beyond that. The response times in Schedule 3 decide how many people you need on site.

Watch out for

Only promise what you can measure. You need metering per circuit, temperature sensors at the rack inlets and node health monitoring. Without your own data you will struggle to dispute a claim.
A grid outage is not force majeure for a datacenter: your generators, UPS and redundant cooling are what the customer is paying for. Clause 13.2 says so, and experienced customers will insist on it.
Check that the customer loads its A and B feeds so that either one can carry the whole rack. Otherwise one feed failing can overload the other and bring the rack down.
Line up the schedule with your own suppliers. You cannot promise a GPU node replacement time shorter than your hardware support contract gives you for parts, or network availability higher than your carriers give you.
The chronic failure exit can unwind a project financed on this contract. Check the trigger with your lenders and keep it limited to the affected services.

An example of how this kind of deal can be structured, to adapt with your own advisers. Not legal advice and not a final agreement. AICapacity is not a party to agreements made from it.

Service level schedule

This schedule is dated [date] and forms part of the [colocation services agreement / data hall lease / GPU capacity agreement] dated [date] (the “Agreement”) between:

(1) [Provider legal name], a company registered in [country] under number [registration number], whose registered office is at [address] (“Provider”); and

(2) [Customer legal name], a company registered in [country] under number [registration number], whose registered office is at [address] (“Customer”),

each a “Party” and together the “Parties”.

Background

(A) Under the Agreement, the Provider provides the Customer with [colocation services / data hall whitespace / GPU compute capacity] at the site described in the Agreement (the “Services”).

(B) This schedule sets out the Provider’s service levels for the Services, how they are measured, and the Customer’s rights if they are not met.

The Parties agree as follows:

1Definitions and interpretation
1. 1.1
  In this schedule:
  1. (a)“A Feed” and “B Feed” mean the two independent power paths serving a Dual-fed rack, separated as described in Schedule 1;
  2. (b)“Availability” means the percentage calculated under clause 3.1;
  3. (c)“Contract Year” means each period of twelve months starting on the first Service Start Date or an anniversary of it;
  4. (d)“Customer Equipment” means equipment, software and other items owned or supplied by or for the Customer and located at or connected to the Site;
  5. (e)“Downtime” means a period during which a Service Element is Unavailable, measured under clause 3.2;
  6. (f)“Dual-fed” describes a rack or item of Customer Equipment connected to both an A Feed and a B Feed, and “Single-fed” one connected to a single feed;
  7. (g)“Emergency Maintenance” means urgent work needed to prevent or remedy an imminent risk to people, the Site or the continuity of the Services, which cannot reasonably wait for the notice required for Planned Maintenance;
  8. (h)“Environmental Range” means the temperature and humidity ranges stated in Schedule 1;
  9. (i)“Excluded Event” means an event or circumstance listed in clause 13.1;
  10. (j)“GPU Node” means a server with one or more GPUs or other accelerators made available to the Customer under the Agreement, as described in Schedule 1;
  11. (k)“Incident” means an unplanned interruption to, or reduction in the quality of, a Service, or an event creating a material risk of one;
  12. (l)“Measurement Period” means a calendar month, or the part of one in which the relevant Service Element is provided;
  13. (m)“Monthly Charges” means the recurring charges under the Agreement for the affected Services in the relevant period, excluding metered energy, one-off charges and costs passed through at cost;
  14. (n)“Planned Maintenance” means maintenance notified under clause 10.1 and carried out in accordance with section 10;
  15. (o)“Portal” means the Provider’s online customer portal or ticketing system;
  16. (p)“Priority” means the priority level given to an Incident or request under Schedule 3;
  17. (q)“Response Time” means the time from when a request or Incident is logged or detected until a qualified member of the Provider’s staff acknowledges it to the Customer and starts work on it;
  18. (r)“Service Credit” means an amount credited to the Customer under section 11 and Schedule 2;
  19. (s)“Service Element” means each of power, environment, network, cross-connects, GPU Nodes and remote hands, where marked as applicable in Schedule 1;
  20. (t)“Service Level” means the standard for a Service Element set out in sections 4 to 8 and Schedules 1 and 3;
  21. (u)“Service Start Date” means, for each Service Element, the date it is first made available to the Customer; and
  22. (v)“Unavailable” has the meaning given for each Service Element in sections 4 to 7.
2. 1.2
  Terms not defined in this schedule have the meanings given in the Agreement. References to sections, clauses and Schedules are to those of this schedule, and Schedules 1 to 3 form part of it.
3. 1.3
  On Service Levels, Service Credits, Incidents and maintenance, this schedule prevails over the rest of the Agreement if they conflict. On any other matter the rest of the Agreement prevails.
2Application
1. 2.1
  The Provider shall meet or exceed each Service Level from the Service Start Date of the relevant Service Element.
2. 2.2
  Service Levels apply only to the Service Elements marked as applicable in Schedule 1, and are measured separately for each site, data hall or Customer area unless Schedule 1 states otherwise.
3. 2.3
  Before each Service Start Date, the Parties shall record in writing the circuits, racks, cross-connects and GPU Nodes covered and the measurement points referred to in Schedule 1, and shall update that record when the Services change.
3Measurement and reporting
1. 3.1
  Availability is calculated for each Service Element and Measurement Period as (Total Minutes − Excluded Minutes − Downtime Minutes) ÷ (Total Minutes − Excluded Minutes) × 100, where:
  1. (a)“Total Minutes” is the number of minutes in the Measurement Period;
  2. (b)“Excluded Minutes” is the number of minutes during which the Service Element was Unavailable because of an Excluded Event; and
  3. (c)“Downtime Minutes” is the number of minutes of Downtime, other than Excluded Minutes.
  Drafting note. For power and environment, Availability is worked out per rack (or per circuit, if Schedule 1 says so); for GPU Nodes, clause 7.3 applies. As a guide, a 30-day month has 43,200 minutes: 99.999% allows about 26 seconds of Downtime, 99.99% about 4 minutes and 99.9% about 43 minutes.
2. 3.2
  Downtime starts when the Provider’s monitoring records that the Service Element is Unavailable or, if earlier, when the Customer logs an Incident reporting it, provided the Provider later confirms the Unavailability. Downtime ends when the monitoring records that the Service Element has been restored or, without such a record, when the Provider notifies the Customer of restoration.
3. 3.3
  The Provider shall maintain monitoring sufficient to measure each Service Level, including power metering for each [rack / circuit] and sensors at the measurement points in Schedule 1. Its records are the primary record, but the Customer may submit its own data, and if they differ the Parties shall review both in good faith.
4. 3.4
  Within [10] Business Days after each Measurement Period, the Provider shall publish on the Portal a report showing:
  1. (a)the Availability of each Service Element;
  2. (b)each Incident, with its Priority, duration and cause;
  3. (c)the Planned Maintenance and Emergency Maintenance carried out;
  4. (d)the Response Times achieved against Schedule 3;
  5. (e)a summary of the environmental readings;
  6. (f)the load on the A Feed and B Feed of each Dual-fed rack against the loading limit in Schedule 1; and
  7. (g)any Service Credits the Provider considers due.
5. 3.5
  The Provider shall keep the underlying records for at least [24] months and, on reasonable notice and not more than [once] in any Contract Year, let the Customer or an independent auditor bound by confidentiality inspect them.
4Power
1. 4.1
  The Provider shall deliver power to each Customer circuit at the voltage, frequency and capacity stated in the Agreement and within the tolerances in Schedule 1.
2. 4.2
  A power feed is Unavailable when the supply at the Customer’s [rack power distribution unit / circuit breaker] is interrupted, or is outside the tolerances in Schedule 1 for longer than the period stated there.
3. 4.3
  For Dual-fed racks, the Service Level is stated in Schedule 1, and Downtime occurs only while the A Feed and the B Feed are both Unavailable. Loss of one feed alone is not Downtime, but is a Priority 2 Incident under section 9 and Schedule 3.
  Drafting note. Commonly 100% for correctly loaded dual-fed racks where the power paths are fully independent (2N or similar), and 99.99% to 99.999% where the paths share components. Promise only what your design supports.
4. 4.4
  For Single-fed racks, the Service Level is stated in Schedule 1, and Downtime occurs while the feed is Unavailable.
5. 4.5
  The power Service Level does not apply to a rack or circuit while the Customer’s load exceeds the contracted capacity or, for a Dual-fed rack, while the combined load on both feeds exceeds the loading limit in Schedule 1, so that one feed alone could not carry it.
  Drafting note. In an A+B setup each feed must be able to carry the whole rack if the other fails. If the equipment draws more than one feed can carry, losing one feed overloads the other and the rack goes down. This clause makes that the Customer’s risk. The limit is commonly stated as a percentage of the breaker rating of a single feed. The monthly report under clause 3.4 shows the loading, so both sides see a problem coming.
6. 4.6
  Customer Equipment with a single power supply in a Dual-fed rack has the Dual-fed Service Level only if connected through an automatic transfer switch [supplied by the Customer / supplied by the Provider]. Otherwise it is treated as Single-fed.
5Environment
1. 5.1
  The Provider shall keep the air temperature and humidity at the measurement points in Schedule 1 within the Environmental Range, to the Service Level stated in Schedule 1.
  Drafting note. The ranges are commonly set by reference to the recommended or allowable envelope in the ASHRAE thermal guidelines for the relevant equipment class, measured at the rack air inlet. Check them against the Customer’s equipment specifications. Wider ranges allow more free cooling and lower energy cost. State the numbers in Schedule 1 rather than referring to the guideline in general terms.
2. 5.2
  The environment is Unavailable at a measurement point when the reading there is outside the Environmental Range for longer than the period in Schedule 1. Downtime is counted for the racks served by that point.
3. 5.3
  Where the Provider supplies liquid cooling, such as direct-to-chip cooling or rear-door heat exchangers, it shall also keep the supply temperature, flow rate and differential pressure at the points of connection within the ranges in Schedule 1. Liquid cooling is Unavailable when any of them is outside its range for longer than the period stated there.
  Drafting note. For high-density GPU deployments, liquid cooling matters more than room temperature. Agree in the Agreement where the Provider’s responsibility ends and the Customer’s secondary loop begins, the coolant quality, and who maintains the coolant distribution units.
4. 5.4
  The environment Service Level does not apply to a rack while its heat load exceeds the contracted power or density, or while the Customer has not installed the blanking panels, containment or other airflow management required by the Agreement, or has obstructed the airflow or a measurement point.
6Network and cross-connects
1. 6.1
  This section applies only to network services and cross-connects supplied by the Provider itself, and not to services of third-party carriers, even where the Provider placed the order.
2. 6.2
  The network is Unavailable when the Customer cannot send or receive traffic through the Provider’s network at the demarcation point in Schedule 1. Where the Customer has diverse or redundant connections, it is Unavailable only while none of them can pass traffic. The network Service Level is stated in Schedule 1.
3. 6.3
  The Provider shall complete each new cross-connect within the provisioning time, and restore a faulty cross-connect it supplied within the repair time, stated in Schedule 1.
7GPU Nodes
1. 7.1
  This section applies where the Services include GPU Nodes.
2. 7.2
  A GPU Node is Unavailable when, other than because of an Excluded Event:
  1. (a)the Customer cannot access or control it through the interface stated in the Agreement;
  2. (b)any of its accelerators fails the health checks in Schedule 1 or is not visible to the operating system;
  3. (c)its connection to the cluster’s high-speed interconnect or storage network is down; or
  4. (d)the Provider has taken it out of service, other than for Planned Maintenance.
3. 7.3
  GPU Node Availability for a Measurement Period is the total of the minutes for which each contracted GPU Node was available, divided by the total contracted GPU Node minutes, in each case leaving out minutes affected by Excluded Events, expressed as a percentage. The GPU Node Service Level is stated in Schedule 1.
4. 7.4
  If more GPU Nodes in a cluster than the threshold in Schedule 1 are Unavailable at the same time, or the interconnect is split so that the Customer’s workloads cannot run across the cluster as a whole, every GPU Node in that cluster is treated as Unavailable for that period.
  Drafting note. Large training jobs usually run across the whole cluster, so losing a few nodes or a fabric fault can stop all work. Providers may want a higher threshold, or an exception where spare nodes are swapped in within the replacement time in clause 7.5.
5. 7.5
  Where a GPU Node is Unavailable for longer than the replacement time in Schedule 1, the Provider shall replace it with a node of the same or better specification, and the Service Credit in Schedule 2 applies until it does.
6. 7.6
  The Customer is responsible for backing up and checkpointing its workloads, and the Provider is not responsible for data on the local storage of a GPU Node that fails or is replaced. Before such storage leaves the Customer’s allocation, the Provider shall securely erase or destroy it in accordance with the Agreement.
  Drafting note. Customers with sensitive models or data may ask to keep failed drives or to witness their destruction. Agree this, and the erasure standard, in the Agreement.
8Remote hands and support
1. 8.1
  The Provider shall operate a support desk, reachable [24 hours a day, every day of the year] through the Portal and by telephone, staffed by people able to work in English.
2. 8.2
  The Provider shall provide remote hands at the Site [at all times / during Business Hours] within the Response Times in Schedule 3.
3. 8.3
  The Customer may book scheduled remote hands work at least [24] hours ahead, and the Provider shall start it within the time after the booked start stated in Schedule 3.
4. 8.4
  Remote hands work is done on the Customer’s instructions and charged under the Agreement. The Provider is not responsible for the result of correctly following the Customer’s reasonable instructions, but remains responsible for its own negligence, and may refuse instructions that are unsafe, unlawful or against the site rules.
9Incident management and notification
1. 9.1
  The Customer may log Incidents at any time through the Portal or by telephone. The Provider shall give each Incident a reference number and a Priority under Schedule 3, and may change the Priority, with reasons, if the facts turn out to be different.
2. 9.2
  The Provider shall notify the Customer’s contacts in Schedule 3 of any Incident that affects, or is likely to affect, the Customer’s Services within the notification time for its Priority, however the Incident came to light.
3. 9.3
  The Provider shall update the Customer at the intervals in Schedule 3 until the Incident is resolved, and then confirm the resolution and the time the Services were restored.
4. 9.4
  For each Priority 1 Incident, the Provider shall deliver:
  1. (a)a preliminary report within [2] Business Days after resolution; and
  2. (b)a root-cause analysis within [10] Business Days after resolution, setting out the timeline, cause, effect on the Customer’s Services, actions taken, and dated measures to prevent a recurrence.
5. 9.5
  If the Provider becomes aware of unauthorised physical access to the Customer’s area or Customer Equipment, it shall notify the Customer without undue delay and within [number] hours at the latest, preserve the relevant access records and camera recordings, and cooperate with the Customer’s investigation.
10Maintenance
1. 10.1
  The Provider shall give at least the notice stated in Schedule 1 of any Planned Maintenance that may affect the Services or reduce their redundancy, describing the work, its expected start and duration, the Services affected, and any reduction in redundancy.
2. 10.2
  The Provider shall carry out Planned Maintenance within the maintenance windows in Schedule 1 where reasonably practicable, and not beyond the maximum stated there. The Customer may, once for each notice and with reasons, ask for the work to be moved, and the Provider shall not unreasonably refuse.
3. 10.3
  For Dual-fed racks, the Provider shall maintain one feed at a time and keep the other available. Reduced redundancy during Planned Maintenance notified under clause 10.1 is not Downtime.
4. 10.4
  Maintenance that runs longer than notified, takes place outside the notified time or affects Services beyond those notified is not Planned Maintenance, and any resulting Unavailability is Downtime.
5. 10.5
  The Provider may carry out Emergency Maintenance with as much notice as is reasonably practicable and shall explain the reasons in writing within [2] Business Days afterwards. Unavailability caused by Emergency Maintenance is Downtime, except that up to [number] hours of it in each Contract Year are treated as caused by an Excluded Event.
  Drafting note. Customers usually argue that emergency maintenance should always count, or “emergency” becomes a loophole; Providers want it excluded. This wording is a middle ground. Set the hours to zero for the customer-friendly version.
11Service credits
1. 11.1
  If, in a Measurement Period, the Availability of a Service Element is below its Service Level, or the Provider misses a provisioning, repair, replacement or Response Time, the Customer is entitled to the Service Credit in Schedule 2.
2. 11.2
  Service Credits are a percentage of the Monthly Charges for the affected racks, circuits, GPU Nodes or other Services only, unless Schedule 2 states otherwise.
  Drafting note. The base matters as much as the percentage. Crediting only the affected racks keeps credits proportionate; customers with large deployments may ask for the whole data hall.
3. 11.3
  Service Credits for a Measurement Period shall not exceed [number]% of the Monthly Charges for that Measurement Period. Service Credits for a Contract Year shall not exceed [number]% of the Monthly Charges for that Contract Year.
  Drafting note. Delete the second sentence if there is no annual cap. Caps vary widely, from a small share of the monthly charges to the full monthly charges for the affected Services.
4. 11.4
  Where one event causes more than one Service Level to be missed, only the highest applicable Service Credit is given for it.
5. 11.5
  Confirmed Service Credits are set off against the next invoice. If no further invoice is due because the Agreement has ended, the Provider shall pay them within [30] days. Service Credits have no other cash value.
6. 11.6
  The Parties agree that Service Credits are a price adjustment reflecting the reduced value of the Services, not an estimate of the Customer’s loss and not a penalty.
  Drafting note. Under some legal systems a payment for breach that is out of proportion to the interest it protects can be unenforceable. Framing credits as a price adjustment, and keeping them proportionate, helps. Counsel should confirm the position under the governing law.
7. 11.7
  Service Credits and termination under section 14 are the Customer’s sole and exclusive financial remedies for a failure to meet the Service Levels, except where the failure results from the Provider’s [gross negligence or wilful misconduct] or causes physical damage to Customer Equipment or injury to any person, in which case the liability provisions of the Agreement apply. Service Credits [do / do not] count towards the Provider’s limit of liability under the Agreement.
  Drafting note. Exclusive remedy is a major negotiating point. Providers want it; larger customers often accept it only with meaningful credits and a clear chronic failure right. If credits count towards the liability cap, a bad year of credits reduces what is left for other claims.
12Claiming service credits
1. 12.1
  To claim a Service Credit, the Customer shall give notice through the Portal within [30] days after the later of the end of the Measurement Period and its receipt of the report under clause 3.4 for that period, identifying the Service Element, the times affected and any Incident reference numbers.
2. 12.2
  Service Credits shown as due in the report under clause 3.4(g) are applied automatically, without a claim.
  Drafting note. Automatic credits save administration and argument, and larger customers increasingly expect them. If you prefer credits on claim only, replace this clause with “Not used.”
3. 12.3
  The Provider shall accept or dispute a claim within [10] Business Days, giving its reasons and the monitoring data it relies on.
4. 12.4
  A Service Credit neither claimed within the period in clause 12.1 nor applied under clause 12.2 is waived.
5. 12.5
  Either Party may escalate a disputed claim to the level 3 contacts in Schedule 3. If it is not resolved within [20] Business Days of escalation, either Party may refer it for resolution under section 17.
13Exclusions
1. 13.1
  Subject to clause 13.2, Unavailability or a missed Service Level is not counted to the extent caused by any of the following (each an Excluded Event):
  1. (a)Planned Maintenance carried out in accordance with section 10;
  2. (b)Emergency Maintenance, to the extent stated in clause 10.5;
  3. (c)an act or omission of the Customer, its Affiliates, contractors, end users or visitors, including a breach of the Agreement or the site rules;
  4. (d)a fault in Customer Equipment, or in software, images, firmware or configuration supplied or changed by or for the Customer;
  5. (e)the circumstances described in clauses 4.5 and 5.4;
  6. (f)a failure of third-party carrier services, which are outside section 6 under clause 6.1;
  7. (g)a suspension of the Services that the Provider is entitled to make under the Agreement;
  8. (h)the Customer’s refusal of, or delay in giving, access, approvals or cooperation reasonably needed to restore the Service; and
  9. (i)a Force Majeure Event as defined in the Agreement.
2. 13.2
  None of the following is an Excluded Event, even if it would otherwise be a Force Majeure Event, to the extent the Site’s power, cooling or network systems are designed, or are required by the Agreement to be maintained, to withstand it:
  1. (a)an interruption of the public electricity supply;
  2. (b)an interruption of the mains water supply;
  3. (c)the failure of a single item of equipment or a single distribution path; and
  4. (d)outdoor temperature or weather within the design conditions of the Site.
  Drafting note. Backup generators, UPS and redundant cooling are what the Customer pays for. A grid outage that the design is meant to ride through is the Provider’s risk, not force majeure.
3. 13.3
  During an Excluded Event the Provider shall use reasonable endeavours to restore the Services and keep the Customer informed. The Provider must show, from its monitoring and Incident records, that an Excluded Event caused the Unavailability.
14Persistent failure and termination
1. 14.1
  If the Provider misses the same Service Level in [two] consecutive Measurement Periods, it shall, within [15] Business Days of the Customer’s request, deliver and then carry out a written remediation plan setting out the cause and the steps and dates for meeting the Service Level again.
2. 14.2
  A “Chronic Failure” occurs if:
  1. (a)the Dual-fed power Service Level is missed in [number] Measurement Periods within any [number] consecutive Measurement Periods;
  2. (b)any other Service Level is missed in [number] Measurement Periods within any [number] consecutive Measurement Periods;
  3. (c)a single period of Downtime of Dual-fed power, or of a GPU cluster under clause 7.4, lasts longer than [number] hours; or
  4. (d)the monthly cap in clause 11.3 is reached in [number] Measurement Periods within a Contract Year.
3. 14.3
  Within [90] days after a Chronic Failure, the Customer may terminate the affected Services by written notice, with effect from the date stated in the notice. If the affected Services are [all or substantially all] of the Services, the Customer may instead terminate the whole Agreement.
  Drafting note. This is the Customer’s main protection against a site that keeps failing. For a Provider whose site is financed on the strength of this contract, an easy exit can trigger a default under its financing, so check the trigger with lenders and keep it limited to the affected Services where possible. A common structure is a set number of missed months within a rolling period, plus a single very long outage.
4. 14.4
  On termination under clause 14.3:
  1. (a)no early termination charge or remaining minimum commitment is payable for the terminated Services;
  2. (b)the Provider shall refund charges paid in advance for the terminated Services for any period after termination, and return the related part of any deposit, less undisputed amounts due;
  3. (c)the Provider shall give reasonable help to move the Customer Equipment or workloads for up to [number] months, [at the rates in the Agreement / free of charge]; and
  4. (d)Service Credits accrued before termination remain payable.
15Introduction through the platform
1. 15.1
  The Parties acknowledge that they were introduced through AICapacity and that the terms of use of AICapacity that each of them has accepted continue to apply to any agreement between them arising from that introduction, including the Agreement and this schedule. AICapacity is not a party to the Agreement or this schedule, has no rights or obligations under them, and does not measure, verify or guarantee any Service Level or Service Credit.
16Personal data
1. 16.1
  Operating this schedule involves limited personal data, such as staff contact details, tickets, Site access logs and camera recordings. Each Party shall process it only for the purposes of the Agreement and in compliance with applicable data protection law, including the General Data Protection Regulation (EU) 2016/679, and acts as an independent controller of the personal data it receives.
2. 16.2
  Where the Provider processes personal data on the Customer’s behalf, for example in workloads on GPU Nodes or on storage media handled by remote hands, it does so as processor under the data processing terms of the Agreement. If there are none, the Parties shall agree terms meeting Article 28 of that Regulation before the processing starts.
17Governing law and disputes
1. 17.1
  This schedule and any dispute or claim arising out of or in connection with it are governed by the law that governs the Agreement, which is the laws of [governing law].
2. 17.2
  Any dispute arising out of or in connection with this schedule, including whether a Service Level was met or a Service Credit is due, shall be resolved under the dispute resolution provisions of the Agreement or, if it has none, finally resolved by [arbitration under the rules of [arbitral institution], with the seat of arbitration in [city] and the proceedings conducted in English / the courts of [country and city]].
  Drafting note. Common choices for Nordic and European capacity deals: Swedish law with arbitration under the SCC Arbitration Rules seated in Stockholm, or English law with arbitration under the LCIA Rules seated in London. Arbitration keeps disputes confidential, which matters for site and pricing information. Keep this the same as in the Agreement: two forums for one contract invites argument about which applies. For disputes purely about measurement data, consider referring the technical question to an independent expert first. Have counsel confirm the choice for your deal.

Schedule 1Service levels and parameters

Mark each Service Element as applicable or not, and complete the parameters for those that apply. Clause references are to this schedule.

Term	To fill in
Applicable Service Elements	Power [yes / no]; environment [yes / no]; network [yes / no]; cross-connects [yes / no]; GPU Nodes [yes / no]; remote hands [yes / no]
Areas covered (clause 2.2)	[Site name], [data hall, suite or cage]; racks and nodes as listed in [appendix]
Power configuration	[Dual-fed / Single-fed]; [number] circuits of [number] A at [number] V, [single-phase / three-phase]
Independence of A Feed and B Feed	Separate paths back to [UPS / switchboard / transformer] level
Power tolerances (clauses 4.1 and 4.2)	Voltage within [number]% and frequency within [number] Hz of nominal; a feed is Unavailable after [number] consecutive seconds outside them
Power Service Level, Dual-fed (clause 4.3)	[100]%
Power Service Level, Single-fed (clause 4.4)	[99.99]%Single-fed racks have no redundancy at the rack, so the level is lower than for dual-fed.
Dual-fed loading limit (clause 4.5)	Combined load on both feeds not more than [number]% of the breaker rating of one feed
Environmental Range: temperature (clause 5.1)	[number] °C to [number] °C at the rack air inlet
Environmental Range: humidity (clause 5.1)	Relative humidity [number]% to [number]%, or dew point [number] °C to [number] °C
Environment Service Level (clause 5.1)	[99.99]%
Environmental measurement (clause 5.2)	Inlet sensors at [height] m, one per [number] racks or per containment pod; Unavailable after [number] consecutive minutes outside the Environmental Range
Liquid cooling (clause 5.3)	Supply temperature [number] °C to [number] °C; flow at least [number] litres per minute per [rack / coolant distribution unit]; differential pressure [number] to [number] kPa; measured at [point of connection]; Unavailable after [number] consecutive minutes outside range
Network (clause 6.2)	Demarcation point: [such as the Provider’s port facing the Customer’s router]; Service Level: [99.99]%
Cross-connects (clause 6.3)	Provisioning: [number] Business Days from accepted order; repair: [number] hours from fault report
GPU Nodes (section 7)	[number] nodes, each with [number] accelerators of [model], [memory], [interconnect] and [local storage], in [number] clusters
GPU health checks (clause 7.2)	[Describe the agreed diagnostics and how often they run]
GPU Node Service Level (clause 7.3)	[number]%Usually lower than facility power levels, because individual GPUs and nodes fail far more often than power systems. Choose a level your hardware support contract and spare pool can deliver.
Cluster threshold (clause 7.4)	More than [number]% of the GPU Nodes in a cluster Unavailable at the same time
GPU Node replacement time (clause 7.5)	[number] hours from the GPU Node becoming Unavailable
Planned Maintenance (clauses 10.1 and 10.2)	Notice: at least [number] Business Days, or [number] for work reducing power or cooling redundancy; windows: [days], [start time] to [end time] [time zone]; maximum: [number] hours per Measurement Period per Service Element

Schedule 2Service credits

Service Credits are a percentage of the Monthly Charges for the affected Services (clause 11.2), subject to the caps in clause 11.3, and claimed under section 12. Only the credit for the band Availability falls into applies; bands do not add up.

Term	To fill in
Power, Dual-fed	Availability below [100]% and at least [99.99]%: [number]%; below [99.99]% and at least [99.9]%: [number]%; below [99.9]%: [number]% of the Monthly Charges for the affected racksSome contracts instead give a credit for each started period of Downtime, such as each started half hour. Either works; be consistent across Service Elements.
Power, Single-fed	Below [99.99]% and at least [99.9]%: [number]%; below [99.9]%: [number]% of the Monthly Charges for the affected racks
Environment	Below [99.99]% and at least [99.9]%: [number]%; below [99.9]%: [number]% of the Monthly Charges for the affected racks
Network	Below [99.99]% and at least [99.9]%: [number]%; below [99.9]%: [number]% of the Monthly Charges for the affected network services
Cross-connects	Provisioning: [number]% of the installation charge per Business Day late; repair: [number]% of that cross-connect’s monthly charge per started [number] hours late
GPU Nodes	Below [number]% and at least [number]%: [number]%; below [number]% and at least [number]%: [number]%; below [number]%: [number]% of the Monthly Charges for the GPU Nodes in the affected cluster
GPU Node replacement late (clause 7.5)	The charges for that GPU Node from the end of the replacement time until it is replaced or restoredIn effect a refund of the node-hours lost. Easy to calculate where compute is priced per GPU-hour.
Remote hands	Per missed Response Time: [amount] or [number]% of the charge for that request, whichever is greater
Caps (clause 11.3)	Monthly: [number]% of the Monthly Charges for the Measurement Period; annual: [number]% of the Monthly Charges for the Contract Year, or “Not used”

Schedule 3Incident priorities, response times and contacts

Times run around the clock unless stated otherwise. “Notify” refers to clause 9.2, “update” to clause 9.3 and “response” to the Response Time.

Term	To fill in
Priority 1: critical	Loss of power to a Dual-fed rack; environment outside the Environmental Range at [number] or more measurement points; loss of the Provider’s network; a GPU cluster Unavailable under clause 7.4; or a threat to safety or security. Notify in [15] minutes; respond in [15] minutes; update every [30] minutes.
Priority 2: major	Loss of one feed to a Dual-fed rack; loss of power or cooling redundancy; environment outside range at one measurement point; a single GPU Node Unavailable; or a cross-connect fault. Notify in [30] minutes; respond in [1] hour; update every [2] hours.
Priority 3: minor	Degradation with no current effect on the Customer’s Services, or another reported fault. Notify in [4] hours; respond in [4] hours; update [daily].
Remote hands (clauses 8.2 and 8.3)	Urgent: respond in [30] minutes; standard: respond in [4] hours; scheduled: start within [number] minutes of the booked time
Provider escalation	Level 1: support desk, [telephone], [email], Portal; level 2: [name or role], [telephone], [email]; level 3: [name or role], [telephone], [email]
Customer contacts and escalation	Notifications: [names or roles], [telephone], [email], with one reachable at all times; level 3: [name or role], [telephone], [email]

Signed for and on behalf of the Provider

Name

Title

Date

Signature

Signed for and on behalf of the Customer

Name

Title

Date

Signature

Ready to put a deal on paper?

Templates help once there is a counterparty. Operators find theirs through scored, anonymous requests; buyers by placing one.

List your capacity All templates

Service level schedule

How this model works

How it works

Good for

How the money works

Watch out for

Service level schedule

Background

1Definitions and interpretation

2Application

3Measurement and reporting

4Power

5Environment

6Network and cross-connects

7GPU Nodes

8Remote hands and support

9Incident management and notification

10Maintenance

11Service credits

12Claiming service credits

13Exclusions

14Persistent failure and termination

15Introduction through the platform

16Personal data

17Governing law and disputes

Schedule 1Service levels and parameters

Schedule 2Service credits

Schedule 3Incident priorities, response times and contacts

Ready to put a deal on paper?