Reflections on the hosting provider failure

SiteGround is one of my favorite hosting providers for medium-sized websites. However, they had one of the longest downtime I experienced on one of their data centers on the 19th of June 2022 lasting over 17 hours.

I got notified about one of the websites I maintain being offline by the uptime monitor. SiteGround themselves did not notify me about the failure (which was disappointing).

As always, lessons are learned. Some of my notes:

Good old backup systems

Always have a remote backup of the files and database, it’s a pure minimum. The backups should be run regularly. Some hosting providers provide automatic backup (which is a great tool), however, the backups are stored in their system making them inaccessible if the hosting provider is down.

Ideally, have a script that backs it up remotely. Keep the backups secure and delete them as per the agreement with the client. Keep in mind the GDPR regulations and ensure that you are allowed to store backups at certain geophysical locations and are securely stored with a tiered level of access.

Diversify

Don’t put all your eggs in one basket, as they say.

Do not store the domain, web hosting, and email with one provider. Instead, if possible try to host different web services with different providers. For example, use a reliable company as a domain registrar. Use another company for emails and another to host files.

For simplicity, I recommend purchasing SSL certs with the web hosting provider. It’s possible to purchase it with a 3rd party, however, I noticed the installation process is generally easier and if there are issues, the support is more eager to help.

Do not lock yourself out of the provider’s system

It’s a standard where hosting providers use a two-stop verification code to log in. The access code is being sent to the email address associated with the account. However, if your emails are down then it will prevent you from logging in.
This makes contacting support even more difficult – or in extreme situations even impossible.
Many hosting providers have a system for emergency or secondary login email – set it up and do not get locked out.

Domain registrar

The weakest chain would be the domain registrar.

Pick a reliable domain registrar. Study their uptime history. In case of emergency, set the domain to use a different DNS. Keep in mind the propagation time.

Files and database

If your web hosting is down – migrate the latest website backup to a different server and point the domain there using DNS. Again, keep in mind the propagation time. Check the TTL time on the DNS table.

Conclusion

Use common sense, do not lock yourself out of the domain. My notes above relate to small and large systems. That said having a dedicated server managed by engineers might still cause some issues. Have an emergency procedure and alternatives in place.