4 posts tagged with "cloud"

Introduction​

Incident updates on the public status pages of your cloud providers are often the first indication that they might have an outage. Providers also post updates about upcoming and ongoing maintenance on their status pages. Thus, monitoring your cloud status pages becomes crucial to your business operations. This article will guide you through the process of effectively monitoring such status pages.

1. Identify Your Cloud Providers
2. Locate Their Public Status Pages
3. Understand the Status Page Structure
4. Configure Notifications
5. Best Practices
6. Include in Your Incident Response Plan
7. Use a Monitoring Tool
8. Conclusion
9. FAQ

Identify Your Cloud Providers​

Work with your Dev/Ops/SRE and IT teams to come up with a comprehensive list of your cloud providers. Any service that is not managed by your teams is by definition a cloud service. Although we focus on Cloud providers - i.e. providers that let you deploy your services on their infrastructure - this article is equally applicable to any of your external SaaS vendors.

Locate Their Public Status Pages​

Every cloud provider has a public status page. You can find the link either on their company website, or by doing a web search. The status page software is either managed by your cloud provider, or outsourced to another service like Atlassian Statuspage or Instatus. Many observability and incident management providers like Incident.io and BetterStack also offer public status pages.

Understand the Status Page Structure​

There is no official standard for status page formats but most of them use a similar visual layout. The common terms used to describe incident states are "Major/Minor outage", "Maintenance", "Informational", "Monitoring", and "Resolved".

Status pages will have any ongoing incidents at the top, followed by a list of components or services, followed by past incidents. Clicking on the ongoing incident link will take you to a detailed description of the incident.

An example from the Twilio status page:

Configure Notifications​

Instead of periodically visiting status pages you can choose to sign up to receive notifications when there is an incident created, updated or resolved. Depending on your provider, status pages offer different modes of notification.

• SMS
• Slack
• Email
• RSS feed
• Google Chat
• Discord
• Webhooks

Some status pages offer only one or two options, or sometimes no options at all. If the status page is managed by someone other than your cloud provider, your cloud provider can choose to enable/disable some of the available notification options. For an example, both DigitalOcean and Mailgun use Atlassian Statuspage. DigitalOcean allows you to subscribe using many channels:

whereas Mailgun has disabled all options

This is as of this writing. Providers can modify these options over time depending on their business requirements.

Notification Challenges​

Your notifications should be delivered in a way that ensures the right team in your organization receives the alerts. If the team uses Slack that is where you want the notifications. If it's Discord, the notifications should go to a Discord channel.

The status pages used by your providers can have different notification options, which can pose a challenge. They might not offer the option you want. Some providers may have your chosen option, some might not. See the section on Use a Monitoring Tool on how to mitigate this.

Best Practices​

Filtering Your Monitors​

Cloud providers have many, sometimes hundreds, services in different locations across the globe. A cloud provider's status page shows incidents across all of them. Your team should receive notifications only for the services they use, and in the regions they use them in. Most status pages have an option to choose the services and the regions. Utilize this feature so that your team is not flooded with unnecessary notifications.

E.g. The Fastmail status page which is hosted by Instatus has options to sign up for notifications for specific components:

In some large cloud providers like Google Cloud, it can become difficult to sign up for specific components and regions. Let's say you use Google Kubernetes Engine in us-central1. Currently the Google Cloud status page offers no way to receive notifications for only GKE in us-central1.

Do Periodic Reviews​

Status pages keep changing. Your cloud provider may choose to add/remove services, switch to a different status page provider, or add/remove notification modes.

Have a Single View Across All Providers​

To check if any of your cloud providers have an outage, a single visual way where all your providers show up is a must. In the absence of a dedicated monitoring tool that monitors your cloud provider status pages, a poor substitute will be your notification channel. If it's Slack, you can configure the notifications to go into a specific Slack channel. However, it can be difficult to search for past incidents as well as look at ongoing incidents with Slack.

Include in Your Incident Response Plan​

Irrespective of your chosen notification mode, ensure that your incident response plan includes cloud provider alerts. Determine the right priority of such alerts so that your team can respond effectively. Include cloud provider alerts in your incident response plans so that teams can correlate alerts from other parts of your systems with cloud provider alerts to dig down faster into the root cause.

Use a Monitoring Tool​

As noted in the previous sections, there are various challenges to monitoring cloud providers' status pages by yourself, unless you have only one or two such providers. There are various tools which aim to solve these pain points. IncidentHub is a SaaS tool created specifically to solve these challenges faced by Dev/Ops/SRE and IT Teams. You can create a free account which comes with 20 status page monitors and try it out.

IncidentHub monitors hundreds of cloud provider status pages periodically. It can send you notifications over the medium you choose - Email, Slack, PagerDuty, Discord, MS Teams, etc. IncidentHub also gives you a single dashboard where you can view ongoing and past incidents with your cloud providers:

The Benefits of Using a Monitoring Tool​

The benefits of using a dedicated tool which monitors cloud status pages:

• Offers a single normalized view across cloud providers' status pages
• Hides the complexity of different status page formats
• Detects and handles changing status page formats over time
• Lets you choose the notification mode you want for alerts
• Offers notification modes not available in the status page

Conclusion​

Monitoring public status pages of cloud providers should form a key part of your monitoring strategy to maintain operational effectiveness and customer trust. Your team can stay informed and responsive during cloud service disruptions. There are various challenges in doing this by yourself - heterogeneous status page formats, non-overlapping notification modes, non-standard incident updates, and changing status page structures. A status page monitoring tool like IncidentHub can mitigate all these issues.

FAQ​

Why should I monitor my cloud provider status pages?

Your cloud providers publish information about ongoing incidents and maintenance on their public status pages. Such disruptions can affect your business operations.

What if I am not able to locate a cloud provider's status page?

Cloud providers have a link to their status page on their website or you can find it using web search. If you are unable to locate it please get in touch with us at support@incidenthub.cloud and we will try our best to help you.

What is the best way to receive notifications?

The best way to receive notifications about cloud provider incidents is specific to your team. Discuss with your team what would make it most effective.

Is there a standard status page format?

There is no standard for a status page format. However, many cloud providers use one of the popular status page services like Atlassian Statuspage or Instatus. Providers using the same status page service will have a similar format. Some providers have their own format - like Google Cloud and Amazon Web Services.

What are the benefits of using a dedicated status page monitoring tool?

A dedicated status page monitoring tool smoothens out the differences between different cloud providers' status pages and gives you the option to receive notifications in your chosen way.

Chances are, most of your third-party cloud and SaaS dependencies are globally distributed and have many regions of operation. Chances are, your applications use a subset of a cloud or SaaS service. If you are monitoring such a service, why should you receive alerts for all regions or every single component in the service?

E.g. if you use Digital Ocean, you might be using Kubernetes in their US locations (NYC and SFO). You would want to know only when there is an outage in one of these locations. Digital Ocean's status page gives you the option to subscribe to outages across the board - it’s all or nothing. This is the case with most services with a few exceptions.

Choosing Specific Components to Monitor​

You can now choose which components/regions you wish to monitor in IncidentHub. Let us continue with our Digital Ocean example.

You can choose to monitor all components:

or a subset that is relevant to you:

Once you save this configuration, you will be alerted only for outages that affect these components.

Adding/Removing Components​

You can always go back and edit the components later. This is helpful when you start using say, Kubernetes in a new region, or new components. In your IncidentHub dashboard, you should see the "Edit Components" button next to your list of services.

Benefits​

• This new feature will help you to receive only relevant and actionable alerts. If you are a developer you need not worry about receiving irrelevant alerts for components your application does not even use.
• SRE/Ops teams can react to infrastructure issues quicker without wading through noise and correlate those with outages reported in their own applications.
• If you are in an IT Team with hundreds or thousands of users depending on tools like Zoom, Slack, or Google Workspace, you can react to issues before your users start logging helpdesk tickets.

This powerful new feature, which significantly reduces alert noise, is being rolled out to eligible services as of this writing. Log in to your IncidentHub account today to start customizing your monitoring settings. For a step-by-step guide on how to set up your custom monitoring preferences, check out our knowledge base article. We would love to hear how this new feature is working for you.

Watch this blog or our X/LinkedIn feeds for updates on more exciting new features.

Why should you monitor your third-party Cloud and SaaS vendors if you are in SRE/Ops?

As part of an SRE team, your primary responsibility is ensuring the reliability of your applications. What makes you responsible for monitoring services that you don't even manage? Third-party services are just like yours - with SLAs. And outages happen, affecting you as well as many others who depend on them.

It's a no-brainer that you should know when such outages happen to be on top of things if/when it affects your running applications.

Most of your third party dependencies will have a public status page or a Twitter account where they publish updates on their outages. Here are some seemingly easy ways to monitor these pages

• Subscribe to the RSS feed of these pages
• Follow the Twitter account
• Sign up for Slack, Email, SMS notifications on the status page itself if the page supports these

But if you have tried it, it's not that easy

• Not all pages have RSS feeds
• Some have Slack, Email, SMS integration - some don't
• Some don't have a Twitter account
• You need to sign up on all of these pages one by one, and all services may not support the same notification channel

You can easily end up doing this one by one for 10-15 or more service providers. Let's do a quick check. Which services in this list below do you use in your stack?

• DNS - GCP/GoDaddy/UltraDNS/Route53
• Cloud/PaaS - GCP/AWS/Azure/DigitalOcean/Heroku/Render/Railway/Hetzner
• Monitoring - Grafana Cloud/DataDog/New Relic/SolarWinds
• On-call management - PagerDuty/OpsGenie
• Email - Google Workspace/Zoho
• Communication - Zoom/Slack
• Collaboration - Atlassian Jira/Confluence
• Source code - GitLab/GitHub
• CI/CD/GitOps - TravisCI/CircleCI/CodeFresh
• CDN/Content delivery/ - Cloudflare/CDNJS/Fastly/Akamai
• SMTP providers - SMTP.com/SendGrid
• Payments - PayPal/Stripe
• Artifact Repo - Maven/DockerHub.Quay.io
• Others - OpenAI/Apple Dev Platform/Meta Platform
• Marketing - MailChimp/Hubspot
• Auth - Okta/Clerk/Auth0

This is a small list. You may not have all of these, or may have more/others, but you get the point.

Like any self-respecting Ops Engineer/SRE, you would probably want to whip up a script and write this check-pages-and-notify-in-one-place tool by yourself. I know, because I've worked in Ops/SRE roles for the better part of my career, and NIH is a very real thing. Here's why it's not a great idea

• Any software you write has to be maintained. Say your org starts using a new service which does not have an RSS feed on the status page. What now?
• Who monitors the monitor? How do you know when your script is not running?
• You probably have better uses for your time

IncidentHub was built to solve precisely these problems - so you can focus on what's important, and hand off monitoring third-party services to something that was built with that goal in mind. So stop hacking together scripts to monitor public status pages, and try it out.

If you have a software-based business, you are using at least a few cloud based tools. It does not matter if you are a solo developer, or part of a 50-member team in a large organization. Take this random list and chances are you are using at least half of them:

• Zoom
• Google Workspace
• Slack
• Public cloud/PaaS - GCP/[AWS]/Azure/Render/Heroku/Railway/DigitalOcean/Hetzner
• PagerDuty/Opsgenie
• Cdnjs
• DockerHub
• GitLab/GitHub
• TravisCI/CircleCI/Semaphore
• Let’s Encrypt

Your entire business - irrespective of org or market size - including your development tools, collaboration/communication tools, infrastructure and hosting, monitoring, even email - is dependent on services that you don’t control. They are provided by other vendors.

Of course, you pay for some of them and they all have SLAs. Having an SLA does not translate to 100% uptime. Companies will try their best to meet SLAs - which promise a percentage of uptime (usually 99.xx). There are going to be incidents in your providers at some point, and the effect will cascade to the service that you provide to your customers. This means that your own product’s SLA can be breached due to causes outside your control.

Can you not ask the service provider to notify you directly when this happens? Unlikely, unless you are a really big enterprise. However, most of them have public status pages where you can sign up to receive these alerts over SMS, email, Slack, etc.

The downside is - if you have 50 such services, you have to sign up on 50 pages, one by one. If you want to change your notification channel (another Slack channel, or SMS instead of Slack), you have to edit it on each of those 50 pages.

How does knowing about such issues help you? A few examples (true stories) will illustrate this

• Public cloud outages that are yet to impact your applications. If you get to know beforehand that your cloud vendor has an ongoing incident in your region, you can take preventive steps so that your applications are not affected.
• Paging service outages. Your on-call teams can miss alerts because your paging service is unable to send alerts.
• Delayed/missing messages in your communication tool. Your remote teams are not in sync because your comm tool is dropping only some, not all, messages.
• Your hosted Git repo is throwing errors, while your customer waits for a critical bug fix.

Knowing that there is something wrong with the SaaS/cloud provider gives you an opportunity to do something about it, proactively.

There is no single place, no easy way where you can

• Choose services to monitor
• Choose a channel to receive alerts

This is why we built IncidentHub - based on years of real-world experience. The UI is very simple so that receiving your first alert does not involve more than 2 steps. Check out the demo video below, and try it out yourself at https://incidenthub.cloud/

Originally published on LinkedIn