While people often look for the reassurance of formal service level agreements (SLAs), in the online world where so many components of a cloud-based system are entirely outside the control of the provider these may not be of much practical use. In addition to the platform on which the Affinity application is hosted we integrate with other carefully selected third party vendors to leverage services such as highly reliable email delivery and SMS text services. Each of these independent providers has the potential to break and affect our system and there’s little if anything we can do about that. In reality we have thankfully had absolutely minimal problems with our hosting partner (typically measured in minutes each year rather than hours), but despite that why would we make promises we may not be able to keep?
The issue of undeliverable promises aside, where uptime guarantees are offered they are always going to be weighted so much in favour of the vendor as to be effectively useless anyway. An admin-intensive claim process will allow a small proportion of the monthly bill to be reclaimed as credit towards future bills.
Even the biggest providers (Twitter, Facebook, etc.) have downtime every so often; the practical consideration should be to seek transparency about outages, whether that is a complete server loss or a critical software bug which renders the application unusable. Check for a regularly updated status page, or news items on the vendor’s website and/or social media highlighting any problems, and reassuring customers about their timely resolution. A small number of service-affecting issues and prompt resolution in the event when they occur is more meaningful than promises of system uptime which can’t realistically be delivered upon in a cloud environment.
Please sign in to leave a comment.