A public service-status page gives people a place to look for updates about service availability. ALCO’s status page requires no sign-in, so you can consult it without access to an account on the affected service.
The summary color is a starting point. The incident text, affected components, and update times provide more context. A status page is a structured document with its own conventions, and once you know how to read it you can usually work out not just whether something is wrong, but how far along the response is and when to check back.
Our walkthrough demonstrates a quick status check and shows you where to look on ALCO's page. This article is the vocabulary.
Components: is the broken thing the thing you use?
Most status pages break a service into components rather than reporting one overall state. That distinction helps connect a published incident to the task you are trying to complete.
An unfamiliar component name may or may not be the thing you depend on. If a page reports an issue with an authentication service and you cannot sign in, the incident may be relevant; compare its description with your symptoms. If it reports an issue with a reporting or export function and your sign-in is failing, you may be looking at an unrelated incident and concluding your problem is known when it is not.
So read the component names rather than the summary color, and take a moment to identify which ones you actually use. Doing that once, while everything is working, makes every future check faster.
The states, and what each is telling you
Wording varies between providers, but the shape is consistent, and the state tells you something specific about where the response has got to.
Investigating generally indicates that a report or symptoms are being examined. Read the update for what is actually confirmed. Do not assume an estimated resolution time exists, and still report urgent impact or symptoms the published notice does not cover.
Identified generally indicates that the operator has identified a cause or contributing condition. The update should explain the next action. A label by itself is not a promise that a fix is already being applied or that a deadline is certain.
Monitoring generally means a change has been made and its results are being watched. Follow the published guidance about checking your workflow, and report any remaining impact through the appropriate route.
Resolved means the incident is closed. It does not always mean every knock-on effect has cleared — queued mail, delayed jobs and stale sessions can take longer, so follow the provider’s recovery instructions rather than applying account or device changes automatically.
Degraded performance and partial outage are worth distinguishing from a full outage. Degraded usually means slow or intermittent, which is the state most likely to be misread as a local problem — and the one where your report is most useful, because it may be affecting only some paths.
Maintenance and history
Scheduled maintenance is normally listed separately and in advance. If your problem coincides with a maintenance window, compare the listed impact and times with what you are observing, and it is worth finding out how those notices are published so your team hears about them before rather than during.
Many pages also show a history and some form of uptime figure. History is genuinely useful — it tells you whether the thing that just broke has broken repeatedly, which is a different conversation with your provider than a one-off.
Uptime percentages deserve more skepticism. They summarize a period, they depend entirely on what the provider chose to measure and count, and they say nothing about whether the downtime fell across your busiest hour or a quiet weekend. Treat them as context, not as a promise.
Subscribe, and stop refreshing
If the page offers notifications, use them. A subscription may reduce the need to check manually. Review which notifications you have selected and how they will arrive; the frequency depends on the provider and the incident.
It also spreads the load. For a team, agree who will relay relevant updates and where those updates will be recorded. That gives colleagues a common reference without assuming that every person sees each notification.
A one-minute routine
- Find and bookmark the status pages for your critical services now, while nothing is broken.
- Note which components correspond to the things you actually use.
- When something fails, check the component rather than the headline color.
- Read the state to judge how far along the response is, and check the timestamp of the last update.
- Subscribe to updates instead of refreshing.
- Tell your team what you found, distinguishing published information from your own observations.
- If the page is clear and multiple people are affected, report it with what you have observed.
What a green page does not prove
This is the part worth remembering above all the rest. A clear status page means it is not displaying an incident for the service you checked. It is a report of the operator's current knowledge, not a measurement of your experience.
Incidents have to be detected, confirmed and posted, and that sequence takes time — so a genuinely broken service can show green for the first stretch of an event. Problems that affect a small subset of customers, one region, or one network path may never be declared at all, because from the provider's perspective the service is working almost everywhere.
The practical consequence: never let a green page talk you out of evidence. If several colleagues on different networks cannot use something, include both your observations and the page’s state in your report, and your report may be what starts the investigation.
Your next step
Watch the short walkthrough, then spend five minutes today bookmarking the status pages for your mail provider, your hosting, and your two most important applications. Put those links wherever your team keeps support contact details.
If you would like help mapping which services your business genuinely depends on — including the dependencies between them — that is ordinary work for the ALCO team across managed hosting, development and IT support.
Sources and further reading
ALCO training on checking service status: https://alcohq.com/training/checking-service-status
Video walkthrough: https://youtu.be/OLNnIAY7U3U
ALCO help desk services: https://alcohq.com/services/help-desk