SLA Uptime
Last updated: February 26th 2025
- Foundation Health strives for 100% uptime of its API and technology systems required for the delivery of this Agreement (“Systems”).
- Foundation Health shall provide at least a 99.9% per calendar month uptime availability (“Uptime Service Level”) of its Systems.
- Client caused outages shall not be included in any measurement of the Uptime Service Level.
- Foundation Health shall give the Client reasonable advance notice prior to a scheduled downtime maintenance window event and shall use commercially reasonable efforts to minimise any downtime.
- Outages as a result of the Client breaching its obligations under this Agreement or significantly contributed to by Client elements outside of Pharmacy’s reasonable control (such as customer equipment, connectivity etc.) shall not be included in any measurement of the Uptime Service Level.
- All measurements are performed at one (1) minute intervals. The availability measurements shall be carried out by Foundation Health using automated monitoring tools provided by the infrastructure provider (or equivalent).
- The Systems shall be “unavailable” as notified by the monitoring tool or if the Client is unable to access the Systems at any time during the term of the Agreement.
- Monthly average percentage Uptime Service Level is calculated at the end of each calendar month, as the total actual uptime minutes divided by total possible uptime minutes in the month minus the exclusions set out in 3, 4 and 5.
Response Levels
| Priority | Definition | Effort | Response Time | Restore | Resolution Target |
|---|---|---|---|---|---|
| Critical | The Systems are "down" / inaccessible or are severely degraded or produce incorrect results which prevent the routine business operations of the Client. | 24/7/365 | Within 1 hour | Within 4 hours | Within 12 hours |
| Non-critical | Certain non-essential features of the Systems are impaired while most major components of them remain functional and accessible. Errors that are non-disabling or cosmetic, and clearly have little or no impact on the normal operation of the Systems. | During Email Support Hours | Within 1 hour of Email Support Hours | Within 48 Business Hours | Within 30 days |
- Response Time: Time taken for response from Foundation Health once notification of an issue is received.
- Restore: Issue is mitigated to the point that core business operations are able to continue. The service may still be degraded or suboptimal whilst work is being done to fix the issue completely.
- Resolution Target: Target time taken to resolve the issue and fully restore system functionality.
Example of a Critical issue: A complete system outage is caused due to underlying infrastructure problems. A restorative action might be to provide an older but compatible version of the system that can process orders. A resolution would be the restoration of the latest system version.
Example of a Non-critical issue: A change to error handling means that the HTTP status code of a certain class of error is unintentionally changed to a similar but different code (e.g. 400 -> 404). This is considered non-critical as the API call is a 4XX error either way and so business operation should not be affected.
API Enhancements and Changes
- Foundation Health will communicate improvements to our customers in a timely fashion so it is able to take advantage of new features or offerings provided in our API
- Any elimination of a feature will be communicated to customers with advance notice of at least 30 days unless a force majeure event occurs
- Future API versions will be communicated to customers when they become available and a 30 day transition period will be provided for customers to transition to a new API