Is it down, or is it just you?

Something stops working. The page will not load, the application will not sign you in, the file will not save. It can be tempting to connect the failure to the most recent change you remember. That change may be relevant, but it is useful to record what you can observe before choosing an explanation.

The productive question is different and almost mechanical. How widely is this broken? Understanding the apparent scope helps you choose a useful next step. You may not be able to establish the cause yourself, and you do not need to do so before asking for help.

The narrowing sequence

Start with the public status page and any internal notices. Then use the safe checks that are practical and permitted in your environment. Each result is a clue about scope, rather than a conclusive test of the cause.

Does it fail for you on a different device? If the same account works on your phone but not your laptop, record that difference. Device configuration, browser state, network paths, and service behavior may differ. Failure on both devices does not identify a single cause.

Does it fail for a colleague? If someone nearby can complete the same task, note which account, application, and environment they used. That comparison may help investigate account or session differences, but it does not rule out a service issue affecting a subset of users. If several colleagues are affected, include that scope in the report.

Does it fail on a different network? If your organization permits it and the service is available that way, a check using mobile data may provide a useful comparison. Do not bypass required security controls, transfer sensitive work to a personal device, or change equipment settings simply to complete a test. Different results suggest something to investigate; they do not prove where the fault lies.

Does everything from that provider fail, or only one thing? If your email works while one application is unreachable, record that distinction. If several services are affected, a shared dependency may be worth investigating. Support can use that information to compare authentication, name resolution, network paths, and application behavior.

And did anything change? New password, new device, new software, an update installed overnight, a change of office, someone doing work in the comms cupboard yesterday. Record recent changes without assuming that one of them caused the problem. Include an approximate time if you know it.

Use the public status page as an early reference

ALCO publishes a public service-status page, and our short walkthrough shows exactly where to look and how to read what you find. It needs no sign-in, so you can consult it without signing in to the affected service.

Check it early, then compare any published information with what you observe. "Everyone in our office is affected, on two different networks, and the status page shows an open incident on the component we use" is a complete picture in one sentence.

When to wait and when to raise a ticket

If a declared incident matches what you see, follow the published guidance and your organization’s escalation requirements. Subscribe to updates if that option exists so you stop refreshing, tell your colleagues so they stop reporting it individually, and put the workaround in place if there is one. A short note confirming your impact is still worth sending — it helps the provider understand scale — and you should still report urgent impact or symptoms that differ from the published incident.

Raise a ticket promptly when the status page is clear and multiple people are affected. That combination is worth reporting, because it may be the first sign of something not yet detected. Include what your narrowing tests showed.

Raise a ticket too when only you are affected and you have run out of obvious explanations. A single-user problem is real work and often something specific to your account or device — it is simply a different investigation.

Use your organization’s security-reporting route promptly if you see concerning activity, such as mail rules you did not create or messages sent from your account that you did not authorize. Password prompts or signed-out sessions can also have ordinary causes; report the context rather than declaring a breach yourself.

A short triage reference

• Check the public status page and any internal notices.
• If approved and practical, compare the task on another authorized device.
• Ask whether a colleague has seen the same issue; do not share credentials.
• If permitted, compare an approved network path without bypassing security controls.
• Try a second service from the same provider.
• Note anything that changed in the last day, however unrelated it seems.
• Record the observations, report relevant impact, and follow the published guidance.

Keep that list somewhere your team can find it without asking anyone. Most of its value is that it gives people something concrete to do in the first few minutes, instead of refreshing a page and getting annoyed.

What a status page cannot tell you

A clear status page means it is not currently displaying an incident for the service you checked. It does not mean nothing is wrong.

Incidents have to be detected, confirmed and posted, and that takes time — so early in an event the page will legitimately show green while something is genuinely broken. Problems affecting a small subset of customers, one region, or one network path may never be declared at all, because from the provider's side the service really is working for almost everyone.

Trust your own evidence. If several people on different networks cannot use something and the page is clear, include both observations in your report, and your report may be the thing that starts the investigation.

Your next step

Watch the walkthrough, then find your service-status pages — for your mail provider, your hosting, and any critical application — and bookmark them today, while everything is working. Put those links next to your support contact details in whatever document your team actually opens.

Keep the triage reference beside those links. Its purpose is to make the first observations easier to record and share, while leaving diagnosis and consequential changes to the people responsible for 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