Service levels

The CWP (Common Web Platform) contract sets out the services and service levels you can expect from SilverStripe to manage your website. This page provides a summary of these service levels.  


Summary of the service levels

SL No.

Service Level - Simplified Description

Simplified Measure

SL1

Time taken from a signed contract to the Service Desk being ready for an agency (which can then be used to request new websites)

3 business days

SL2

Time taken for a new instance (website) being requested until it is ready

3 business days

SL3

Website availability (uptime)

99.7% per month (exceptions exist)

SL4

Content Management System availability (uptime)

99.7% per month (exceptions exist)

SL5

Backups: Time between requesting a backup and commencement of restoration.

4 hours after media available

SL6

Backup: Maximum time since last successful backup, known as Recovery Point Objective (RPO).

28 hours

SL7

Time taken to restore a website which is protected by the optional ‘Passive Disaster Recovery’ service, following an incident, known as Return to Operation (RTO).

< 20 hours following incident

SL8

Where a website is protected by the optional ‘Passive Disaster Recovery’ service, the maximum amount of time before data is copied off-site. This represents the level of potential data loss should the site be recovered following an incident (RPO).

< 5 minutes

SL9

Time taken to restore a website which is protected by the optional ‘Active Disaster Recovery’ service, following an incident (RTO).

< 4 hours following incident

SL10

Where a website is protected by the optional  ‘Active Disaster Recovery’ service, the maximum amount of time before data is copied off-site. This represents the level of potential data loss should the site be recovered following an incident (RPO).

< 5 minutes

SL11

Length of time between an incident being raised by an agency (via online means) and when acknowledgement occurs

P1, P2 priority: < 60 mins (during business hrs)

P3, P4 priority: < 8 business hrs

SL12

Length of time between an incident being raised by an agency (via telephone) and when acknowledgement occurs

P1, P2 priority: < 15 mins

P3, P4 priority: < 8 business hrs

SL13

Length of time between an automatic outage system being triggered and the relevant agency receiving notice of the outage

< 30 minutes

SL14

Length of time between an incident being identified and a temporary solution (“workaround”) operating.

P1: < 30 minutes

P2: < 120 minutes (exceptions exist)

Not applicable to P3 and P4.

SL15

Length of time between an incident being raised by an agency and work on solving the issue has commenced.

P1: < 30 minutes (24x7)

P2: < 120 mins (during business hours)

Not applicable to P3 and P4.

SL16

Length of time between an incident being identified and when initial diagnosis is complete.

Twice the timeframes in SL15.

SL17

Length of time between an incident being identified and work on solving the issue has satisfactorily completed.

P1: < 120 minutes (24x7)

P2: < 6 hours (during business hours)

Not applicable to P3 and P4.

SilverStripe is responsible for monitoring service levels and reporting to the agency if they haven’t been met. Detailed service level descriptions are in the Service Catalogue.

Contact us for a copy of the Service Catalogue


If SilverStripe doesn’t meet a service level

SilverStripe will calculate a missed service level as a service level credit and include it in the agency’s monthly invoice.


How service level credits are calculated

The calculation is described in detail in the contract, but in simple terms:

  • The credit pool is the maximum that can be paid. This is 40% of the monthly fee.

  • Each service level has a weighting. For example, SL3 (website uptime) has a weighting of 60%. The credit for failing to meet that service level would be monthly fee ($) x 0.6 x 0.4 = service level credit ($).

  • If more than one service level has been missed, the amounts are summed, up to the credit pool maximum.


When service level credits don’t apply

If the agency has caused the problem. For example, if third party developers released code that took the site offline.

Last modified: