desktest.net
GitHub

SaaS Reachability Test Guide

A reference for the desktest.net SaaS Reachability Test. It answers one question for each cloud app: can this workstation reach it, and if not, is the fault your network or the vendor? For every service it runs the same host check twice - once from this browser, once from an independent Cloudflare edge - and compares the two. Use it to triage "Outlook is down" or "myHub won't load" tickets before you escalate to the wrong team.

Open the SaaS Reachability Test ->

What does the SaaS Reachability Test check?

The tool does not log you in and it does not measure speed. It checks whether the hosts your cloud apps live on will answer a network connection from this workstation, and it cross-checks that answer against a vantage point outside your network. Five services are covered today:

For each host the test does two things at once:

  1. Client reachability. A passive no-cors fetch() from this browser to the host. It resolves on a successful TCP and TLS handshake (the host answered from here) and rejects on a DNS, firewall, or TLS failure. The response is opaque, so the status code is not readable - resolution alone is treated as "the host answered."
  2. Edge reachability. A small GET to edge.desktest.net/reach?target=<key>, a Cloudflare Worker that lives off your network. It reports, in readable JSON, whether the Cloudflare edge can reach the same host: { ok, target, reachable, status, ms }.

Comparing the two is the whole point. One check alone can only tell you "it worked" or "it didn't." Two checks from two different networks tell you where it didn't work.

The targets, one by one

Microsoft 365 (Outlook on the web)

Microsoft 365 sign-in is a two-host handshake. The browser first talks to login.microsoftonline.com to authenticate, then to outlook.office365.com to open the mailbox. If a proxy allowlist covers one host but not the other, users see a half-broken experience: the login page loads but the mailbox spins forever, or the reverse. That is why this step checks both hosts and only reports the service reachable when both answer from this browser.

Both hosts sit behind Microsoft's global front end and are almost never down at the same time, so a genuine "both unreachable from the edge too" result usually means a regional Microsoft incident rather than a full outage. Check the tenant's service health before you assume the worst.

Google Workspace

accounts.google.com is the sign-in host for Google and Google Workspace (Gmail, Drive, Docs). If a proxy or content filter blocks it, users cannot sign in to any Google service, so it is the single most useful Google host to probe. Edge key google.

Zoom

zoom.us is Zoom's main host; a GET to the root typically redirects to www.zoom.us, which the client check does not follow (an opaque redirect already proves the host answered). Unreachable from the browser but fine from the edge usually means a meeting-blocking web filter on this network. Edge key zoom.

Slack

slack.com is Slack's front door and sign-in host. Slack also opens WebSocket connections to *.slack.com subdomains once you are in a workspace; this test only confirms the main host is reachable, which is the usual failure point on a filtered network. Edge key slack.

SiteLink myHub

myhub.sitelink.com is the Storable / SiteLink self-storage management front end. A GET to its root typically issues a cross-origin redirect toward myhub.smdservers.net; the client check uses redirect: 'manual' so that redirect is not followed (following it would need the redirect target in this page's connect-src). An opaque-redirect response still resolves, which already proves the host answered. Edge key sitelink.

If you want an end-to-end SiteLink readiness check - browser support matrix, cookies, popups, and a guided login confirmation - use the dedicated SiteLink Readiness Check. This SaaS test is the narrower "is myHub reachable, and whose fault is it?" slice.

The "is it me or them?" logic

Each host produces a pair of answers: did this browser reach it, and did the Cloudflare edge reach it? The four combinations map to four conclusions:

This browserCloudflare edgeConclusionWho fixes it
ReachedReachedReachable, all good. The service is up and this network is not blocking it.Nobody - it works.
Could not reachReachedYour network, proxy, or firewall is blocking it - not the vendor.You / your network admin (local fix).
Could not reachCould not reachThe service is unreachable from the public internet right now - likely a vendor outage or maintenance.The vendor. Wait it out.
ReachedCould not reachUnusual. Usually a transient edge hiccup; trust the successful in-browser reach.Nobody - noted for context.

The middle two rows are the ones that save a ticket from going to the wrong team. "Could not reach here, but the edge reached it fine" means the outage is inside your walls: a firewall rule, a web filter category, or a TLS-intercepting proxy that does not recognise the destination. "Could not reach here, and the edge could not either" means the problem is out on the internet and no change on the workstation will help.

For Microsoft 365 the two hosts are combined: if either host is blocked locally the whole service is flagged as a local block; if either is unreachable from the edge too it is flagged as a likely vendor outage. When the two hosts disagree - one blocked locally, one down at the vendor - the step reports the mixed result and shows both fixes, labelling each host.

Why an outside vantage point? A single reachability check cannot tell a local block from a vendor outage, because both look identical from inside the browser: the fetch just fails. The edge probe is the control. Because it runs on Cloudflare's network, well away from your office, agreement or disagreement with your browser is what isolates the fault.

Reading the results

Each service renders a row with a status badge: Pending (grey), Running (yellow), Pass (green), Warn (yellow), or Fail (red). Expand a row to see the two subcheck lines per host - one for this browser, one for the Cloudflare edge - each with its round-trip time in milliseconds, plus a plain-language note explaining who is at fault.

The verdict panel at the top summarises the whole run with a likely cause and a recommended next step. When a service fails, it names whether the block is local or vendor-side so you know which team to hand it to. A failing verdict also offers a fix checklist under the failing row: the local-block fix (allowlist the host through your firewall/proxy) or the outbound-DNS/UDP fix (resolver, VPN, and UDP 443 checks).

Copy Diagnostic Report copies a plain-text report: timestamps, user agent, and for every host the client result, the edge result, and the second-opinion conclusion. Paste it into a ticket or an email to your network team or the vendor's support. Send to your IT opens the same report in a pre-filled email.

For IT admins: proxy and firewall allowlisting

The test page itself has to load through whatever proxy sits between the user and the internet. If the page will not load at all, allow desktest.net through the edge first. The page has no third-party scripts, analytics, or CDN fonts, so there is nothing else to allowlist for it to render.

The diagnostic contacts these hosts. On a strict allowlist egress, the vendor hosts must be reachable for a clean pass, and edge.desktest.net must be reachable for the second opinion to work:

HostPort / schemeWhy
outlook.office365.com443 / httpsMicrosoft 365 mailbox (Outlook on the web).
login.microsoftonline.com443 / httpsMicrosoft 365 / Entra ID sign-in.
myhub.sitelink.com443 / httpsSiteLink myHub front end.
edge.desktest.net443 / httpsdesktest.net's own Cloudflare Worker (the edge second opinion). Stores nothing.

Microsoft 365

Microsoft publishes its full endpoint list at the Office 365 IP Address and URL web service (the "Microsoft 365 endpoints" documentation). For the two hosts this tool checks, the practical rules are:

SiteLink myHub

General

Behind the scenes

The client check uses fetch() with mode: 'no-cors', cache: 'no-store', credentials: 'omit', and redirect: 'manual', wrapped in an AbortController with an 8 second timeout. No-cors gives back an opaque response: JavaScript cannot read the status, headers, or body, but the promise still resolves on a successful TCP and TLS handshake. Resolution is treated as "the host answered." No cookies or credentials are attached, so the vendor sees only an anonymous connection - the same handshake that opening the login page would make, minus the sign-in.

The edge check is a GET to edge.desktest.net/reach?target=<key> where the key is one of the allowlisted values (m365, mslogin, sitelink). The Worker performs its own server-side reachability test to the mapped host and returns readable JSON. Because the Worker sends access-control-allow-origin: *, the browser can read that JSON directly. The Worker keeps no logs of who asked; it is a stateless reflector.

No business data leaves the browser. There is no telemetry to desktest.net, no analytics beacon, and the only values sent are the fixed target keys to the edge and an anonymous opaque GET to each vendor host. View the page source to confirm the target list.

Elsewhere on the web: