Is It One Site, One Service or Everything?

Monday, 08:50, at Bellweather Logistics. Jonah has four tickets in the queue that arrived between 08:31 and 08:47, from four different buildings. All four say the internet is slow. He opens the first. Mei in the Dover office cannot get the customs portal to load a declaration; it sits on a spinning circle for a minute and then shows half a page. The second ticket, from the Leeds depot, is the same portal. The third, from head office, is the same portal and a note that "everything else seems fine". The fourth is from a driver on his phone in a lay-by. Jonah reads it twice, because the driver is not on any network Bellweather owns. Four buildings, one portal, one lay-by. Nothing at Bellweather is slow. The customs portal is slow for the whole country, and it is going to be slow for the next two hours whatever Jonah does.

Every "the internet is slow" ticket has one of three shapes, and the shape decides who owns it. One site means a single web page or address is slow while everything else is fine. One service means a single system people depend on is slow for everyone who uses it, from everywhere. It might be the conferencing service, the finance system, or the file service in the cloud. Everything means the connection itself is struggling, and every site, every service and every person on it feel it together. The three look identical in the ticket, because the requester has one word for all of them. They are sorted in about a minute by asking what and where. This article is part of our The Internet Is Slow series. The isolation frame in the first article decides whether a ticket is the user, the device, the network or an expectation. This article picks up the ticket when the answer to "what exactly is slow" is a name.

It starts with the three shapes and how to tell them apart in a minute. Then come the service that is slow because the service is slow, and status pages in plain words. Next are the provider's problem and the desk's honest message, the one site a security filter is inspecting, and what the desk says in each case. A short war story and the one-site reply to copy finish the article.

Sorting the Three Shapes in a Minute

The sort takes two questions and one comparison, and the first question is "what exactly is slow". If the requester names a site or a system, ask them to open a second, unrelated site, something plain and reliable, and say whether it loads normally. If the second site is fine, the ticket is one site or one service, and the connection is innocent for now. If the second site is slow too, ask for a third. If that is slow as well, the shape is probably everything. The ticket then belongs to the measurement article in this series. The requester can do this while you are still reading the ticket, which is the point.

The second question is "where else", and it separates one site from one service from everything by geography. A site slow from one building and fine from another is a network problem at the first building, or a filter there. Suppose a site is slow from every building and also slow from a phone on its own mobile service, off the office network entirely. In that case, it is slow at the far end. Nothing in any of your buildings is involved. A phone on its own service is the single most useful comparison the desk has, because it shares nothing with the office network except the far end. Jonah's driver in the lay-by was not a mystery. He was the control group.

The comparison is the desk doing the same thing itself, from a known-good device, on the office network and off it. The desk also notes the time. The far end slow from both: one service, theirs. Slow from the office and fine from the phone: something between the office and the far end, which is the provider, the firewall or a filter. Fine from both while the requester's device is slow: the first article's device branch. The requester is holding a laptop problem with a website's name on it. The whole sort is three browser windows and a phone. I have watched technicians spend an hour on tickets that this would have closed in four minutes. (I was one of them, for a few years.)

The Service That Is Slow Because the Service Is Slow

Most one-service tickets are the service, and the hardest thing for a new technician to accept is that there is nothing to fix. The conferencing service has a bad morning in its own data centre. The finance system's supplier is doing something clumsy. The cloud file service is slow for everyone on the continent. The ticket arrives on your desk because your desk is the only place the requester knows to put it. The symptoms are distinctive once you know them. The same service, from every location, at the same time, for every user, with every other service fine. A phone off the network sees it too. That pattern cannot be produced by anything in your building. It can only be produced by the far end.

The desk has two jobs in this case, and neither is technical. The first is to confirm, quickly, that the far end is the cause, so that nobody restarts a firewall for a problem on another continent. The second is to communicate. Tell the people affected what is slow and that it is the service rather than the connection. Tell them that the desk is watching it and when they will hear again. The first takes a minute with the comparison above and a glance at the service's status page. The second is the subject of the whole Outage Communication series. The specific message, sent within five minutes of the pattern being clear, follows the shape in The First Notice. A slow service that affects everyone is an outage with the lights still on, and it is handled like one.

What the desk does not do is pretend to be fixing it. "We are looking into it" when the looking is finished and the answer is "it's them" buys an hour of silence at the cost of trust. "The finance system is slow for all its customers this morning. Their status page says they are working on it. We will update you at ten" is honest, specific and takes one minute to write. The question of whether a slow application is you, us or them has its own treatment in The Slow Application: Is It You, Us or Them?. That covers the application side; this article only needs the desk to recognise "them" and say so.

Status Pages in Plain Words

A status page is a web page a service publishes about its own health. It lists its parts and whether each is working, degraded or down, with a note on anything being investigated. Most services people depend on have one. The address is usually in the service's help pages or at an obvious "status" address under the service's own name. The desk should keep a short list of the ones its organisation uses, with a line for each on the internal knowledge base. Checking the status page is the second step after the phone comparison, and on a good day it is the whole investigation.

Read status pages the way you read a vendor's optimism: with care. The words have meanings. "Operational" means nothing is known to be wrong, which is not the same as nothing being wrong. "Degraded performance" means the service is up and slow, which is your ticket. "Investigating" means they have noticed; "identified" means they know why. "Monitoring" means they have done something and are watching it. "Resolved" means it is over, in their opinion, which the requester may dispute. A status page that says "operational" while twenty of your people cannot use the service is not lying to you. It is late, and status pages are often late by ten to thirty minutes. Someone at the far end has to agree that there is a problem before the page changes.

So the status page confirms; it does not acquit. If the phone comparison says the far end is slow and the status page says operational, trust the phone and reply to your people accordingly. Then check the page again in fifteen minutes, when it will usually have caught up. Many status pages let the desk subscribe to updates by mail or feed. That subscription, routed to the desk's own mailbox, is the cheapest early warning the desk can buy. Your own organisation's status page tells your people what is slow before they ask. It is a different thing and a worthwhile one. It is covered in A Status Page for a Small Organisation.

The Provider's Problem

The provider is the company that sells the organisation its connection to the internet. When the shape is "everything", it is slow from every device on the site and fine from a phone off the network. In that case, the provider's line is the first suspect after your own firewall. The symptoms are the inverse of the service case: every site, every service, every person on the site, at once. Meanwhile, a phone on its own service and colleagues at other sites are fine. The desk cannot see the provider's equipment and cannot fix the line. What it can do is confirm the shape, take the numbers that the provider will accept, and say something honest to the people affected.

The numbers matter because the provider's first question will be "what are you seeing", and "it's slow" ends the call. What starts the call instead is a speed check from a known-good wired device, taken at the firewall or as near to it as the desk can get. Include the time. Compare it against the same check from the same device on a normal day. The method and the evidence sheet are in Measuring Slow; here the point is that the provider's problem is proved by a number from the wire, not by a count of complaints. Providers also have status pages, usually less informative than the services' ones. A provider's own page saying "a fault in your area" is the rare case where the desk gets to be relieved and annoyed in the same minute.

The honest message for a provider problem has one more line than the service message, because the desk owns the relationship. "The office internet connection is slow for everyone in this building since about half past eight. It is the connection itself rather than any one system. We have reported it to the provider with our measurements. We will update you at ten whether or not we have heard back." People at the site now know three things: it is not their laptop, someone is on it, and when the next word comes. The update at ten goes out even if the news is "nothing yet", because the cadence is the promise. The cadence rules are in Update Cadence During an Incident.

The One Site a Security Filter Is Inspecting

The last shape is the trickiest, because it looks like one site and behaves like a network fault. A single site or service is slow for everyone at the organisation, from every building, wired and wireless. The same site is fast from a phone off the network. The far end is fine. Your connection is fine. Something between the two is handling that one site differently. On most networks that something is a security filter: a web filter, a proxy, or a feature on the firewall. It opens up some kinds of traffic to inspect them for threats before letting them through. Inspection takes work, large downloads take a lot of it, and some sites take more than others. So the filter can turn a fast site into a slow one for everyone without anything being broken.

The tells are the pattern and the content. One site, all users, all locations on your network, fine off it, is the pattern. Large downloads or uploads from that site being the slow part, while its ordinary pages are fine, is the content. So is the site having recently changed how it serves its files. Video and large files through an inspecting filter are the classic case. The desk does not diagnose the filter and absolutely does not work around it. A filter that is inspecting a site is doing its job. The desk's job is to tell the person who owns the filter, with the evidence, that the job is costing more than it should for this one site. Whoever owns security decides whether to tune the filter, exempt the site after a review, or leave it slow and say so. The desk triages and reports; the security owner decides.

Write the handoff as evidence, not as a request to switch anything off. "One site, slow for all users on our network since the tenth, fine from a phone off the network. The slow part is file downloads over about a hundred megabytes; ordinary pages fine. Four tickets this week from three sites." The security owner can act on that note in ten minutes. It is also the kind of note that protects the desk when someone asks later why the filter was changed. Security filters are not an enemy of the desk. They are a colleague who reads everyone's post before delivering it, and sometimes takes a while over the parcels.

What the Desk Says, and What It Never Says

The honest message in all three shapes has the same four parts: what is slow, whose problem it is, what has been done, and when the next word comes. It is short, it uses the service's name rather than "the internet", and it does not blame anyone it cannot prove. The temptation in a provider case is to say "the provider is having problems" before the provider has agreed. In a filter case, it is to say "security is slowing it down" before the security owner has looked. Say what you have measured and whom you have told. The rest is opinion, and opinion in an outage message has a way of being quoted back in the review.

The message also never asks the requester to prove the desk innocent. A reply that lists six speed checks to show the connection is fine answers a question nobody asked and reads as defensive. Mei wanted to file a declaration. She needed to know that the portal was slow for everyone, that it was not her laptop, and when to try again. "The customs portal is slow for all its users this morning, from everywhere. It is their side rather than ours. I will tell you as soon as it recovers." That is the entire reply, and it fits in the time it takes the spinning circle to go round twice.

When several tickets arrive about the same slow service, answer each person and keep the investigation in one place. If you run QuerySolv, the dozen tickets about one slow service can be linked to a single ticket for the incident. Then the technician watching the service has one place to write what changed. Each requester still has their own thread to be answered on. When the service recovers and a requester replies the next day to say it is slow again, that reply reopens their ticket in most tools. That is exactly what you want. A second episode is a second episode, not a fresh mystery. The all-clear, and what to say when it turns out not to have been clear, are in The All-Clear and the Follow-Up.

A Short War Story: The Regulator's Portal at Bluewater Bank

At Bluewater Bank, the compliance team reported for six weeks that the regulator's reporting portal was "unusable in the afternoons". A technician called Dominic checked the bank's connection and found it fine. He told them it was the regulator's site and that nothing could be done. The team accepted this the first three times and escalated the fourth. The head of compliance, Anneke, was by then filing returns from home in the evenings to meet the deadline. She had kept a diary. The portal was fine at home, fine on her phone, and slow only from the bank. It was slow only when downloading the day's return files, which were large. A network engineer read the diary and saw the shape in a minute. After a policy change in the spring, the bank's web filter had been set to inspect every download from the portal's address range. The engineer found that the inspection was timing out on the largest files. The security owner reviewed the portal and exempted its download path from deep inspection the same afternoon. The compliance team filed from their desks the next day. The cost was six weeks of a four-person team working evenings and one escalation to the operations director. There was a deadline missed by a day with a letter to the regulator explaining why. The lesson Dominic took was that "fine from home and slow from here" is not the far end's fault, however famous the far end is. A diary with times in it is worth more than any speed check.

The One-Site Reply

The template below is the reply for the two shapes where the slow thing is not the connection. These are one service slow at the far end, and one site slow through the organisation's own filtering. Part one is the reply to the requester, sent within five minutes of the shape being clear, in plain words with the service named and the next update promised. Part two is the internal note on the ticket, which records the comparison, the status page reading and the handoff. This lets the next technician and the network or security owner see what was checked. Pick the line that matches the shape, delete the other, and keep the times real.

ONE SITE OR ONE SERVICE — REPLY AND NOTE
Ticket: ________   Service or site: ______________   Shape: far end [ ]  filtered [ ]
First noticed: ________   Checked from the office at: ________   From a phone off the network at: ________

1. REPLY TO THE REQUESTER (within five minutes of the shape being clear)
   Thanks for reporting this. ______________ (the service or site) is slow at the moment.
   [far end]  It is slow for all its users, from every location, so it is on their side rather
              than our connection; their status page says: "______________" as of ________.
   [filtered] It is slow only from our network, and we have passed the details to the team
              that owns our web filtering so they can look at how that site is being handled.
   Everything else should be working normally. If you need a workaround today: ______________.
   I will update you at ________ whether or not anything has changed.

2. INTERNAL NOTE (same ticket)
   Second, unrelated site from requester's device: fine [ ]  slow [ ]
   Same service from a known-good device, office network:      fine [ ]  slow [ ]  at ________
   Same service from a phone on its own mobile service:        fine [ ]  slow [ ]  at ________
   Status page reading: ______________ at ________   Subscribed to updates: yes [ ]  no [ ]
   Other tickets about the same service: ______________ (linked to ________)
   Other locations affected: ______________   At home: yes [ ]  no [ ]  unknown [ ]
   Slow part, if one site: pages [ ]  downloads [ ]  uploads [ ]  video [ ]  sign-in [ ]
   Handed to: network owner [ ]  security owner [ ]  nobody needed [ ]  at ________
   Nothing on the network touched: [ ]

3. CLOSING (when the service recovers)
   Recovered at: ________   Confirmed by: status page [ ]  own check [ ]  requester [ ]
   All-clear sent at: ________   Episode count for this service this quarter: ____

Jonah sent the first part to Mei, the Leeds depot and head office at 08:56 with the portal's status page quoted. He sent a text to the driver saying it was the portal and not his phone. The portal came back at 10:40. The all-clear went to all four. The internal note on the linked ticket says "far end, confirmed from a phone in a lay-by". That is a sentence that will make sense to the next technician and to nobody else.

Frequently Asked Questions