Effective Starting: August 6, 2019.
| Version | Date | Change |
| 1.0 | August 6, 2019 | First version of the SLA published |
| 1.1 | September 1, 2020 | Changes involving more than 5 min downtime to be conducted outside core business hours, with 24 hours notice. |
| 1.2 | November 11, 2020 | Updated pre-notification time for micro-outages (< 5 minutes). Updated defect definitions, times to fix and defect update frequency. Added P5 defect definition. |
| 1.3 | December 16, 2021 | Added timezone to change notification schedule and release schedule. Updated terminology. |
| 1.4 | March 27, 2023 | Updated Notification Schedule. |
Availability
Availability means all functions of the Powered by Jumbo Platform are available to Client users in a live production environment as per the Platform Capabilities.
The system is available for customer transactions on average 99.9% of this which means there is a maximum of 60 minutes of non-scheduled downtime in a month. This is subject to any circumstances beyond our control, which may affect this timeframe.
Scheduled Maintenance & Downtime
We will endeavour to coordinate scheduled maintenance and releases during a quiet period to ensure:
- There are no software releases that would affect the End of Draw functions taking place;
- There are no changes to the reporting environment except during quiet periods; and
- There are no releases that have an expected downtime of more than a few minutes.
Our development systems and processes are built around the Agile approach, which provides that frequent small releases to the Powered by Jumbo platform occur on a daily basis. This means that:
- Releases in nearly all instances only affect one component of the larger Powered by Jumbo platform.
- Releases typically occur between the core hours of 7 am – 5 pm AEST, Monday to Friday;
- More significant or risky changes that require extended downtime may be done out of these core hours.
- Application releases last between 0 (no downtime) and 5 minutes, with an average downtime of fewer than 30 seconds.
Change Notification Schedule
| Expected Downtime | Pre Notification Period | How |
|---|---|---|
| No downtime | No pre-notification (no service disruption) |
|
| <= 5 minutes downtime | Target 3 hours (minimum 30 minutes) | Communication of outage via Client Success Team. |
| > 5 minutes downtime | 3 days | Conducted outside core business hours (6:00 AM – 9:00 PM AEST ). Communication of outage via Client Success Team. |
Response Time
The speed with which the application will respond to a mouse click or page change is = < 1s, with the current average around 250ms to be maintained +/- 20%.
In the case of Routine requests, Response Time is the time between that request and the system providing a response.
Incidents
Incident means an occurrence that has an adverse impact on the operation or performance of the Powered by Jumbo platform capabilities, as described in Platform Capabilities.
Definitions Of Severity Levels For Support Priorities
|
Priority Level |
Definitions and Examples |
|---|---|
| P1 | • Site completely down or unresponsive • Account registration or Login • Add to cart • Checkout • Tickets not purchased with provider • All customers are unable to complete core sales processes • All customers are unable to receive emails |
| P2 | • Unable to use a specific high-volume payment method during the sales process • Ticket scoring unavailable for all users • End of Draw unable to be completed • Non-core system unavailable during critical window • Verification provider integration is broken during a large draw • Unable to create new draws (i.e charity content) • Ad running for incorrect product and jackpot |
| P3 | • Secondary or non-core business process unable to be completed • Ad running for incorrect jackpot but correct product • P1 or P2 items that have an acceptable workaround |
| P4 | • Moderately urgent items affecting individual customers • Non-urgent data fixes for a group of customers |
| P5 | • Request for information • Non-urgent updates to a single customer record |
Timeframes For Rectifying Incidents
| Priority Level | Acknowledgement Time | Targets | Update Frequency |
|---|---|---|---|
| P1 | 30 mins | 2 hrs | Every 30 mins |
| P2 | 1 hr | 4 hrs | Every 2 hrs |
| P3 | 4 hrs | 3 days | Daily |
| P4 & P5 | 24 hrs | 3 weeks | Weekly |
Acknowledgement Time means the time between the Client reporting an incident to us and us providing a response/notice which acknowledges the incident and providing the first Incident Update.
Targets means the target timeframe to resolve the incident or have a suitable workaround in place.
Incident Update means written notice from us to the Client during the Target including:
- An estimate of when a Workaround (if available) will be provided;
- An estimate of when a Fix will be provided;
- Any actions which can be performed by the Client to mitigate the impact of the Incident; and
- The current status of the work being done to provide the Workaround or Fix
We have the above plans which will be made available for a nominated representative to view in a secure environment upon written request.
Restore Time Following A Disaster
The time it would take to restore the platform following a catastrophic failure, to enable customer transactions to recommence, is 24 hours.
Recovery Time Objective
If the datastore encounters a catastrophic failure the maximum amount of non-recoverable data is 1 hour, due to the backup regime.