What to do when one site tile goes offline

The short answer

When one tile goes offline, treat it as a failed health check against the URL saved on that site. Open the URL yourself. If you cannot, use that site’s host: the latest deploy, DNS, and the logs. If you can, fix the monitored URL or whatever is blocking the checker, and let the next check run. Do not restart unrelated sites because one tile is red. Do not refresh the dashboard as a repair.

Offline means the check failed — no response, or an error status. It does not, by itself, tell you the cause. The sequence below is how you find the cause without skipping the confirmation that saves you from “fixing” a typo.

Pause the rest of the portfolio

Look at the other tiles before you go deep. One offline tile and a field of online tiles means the problem is local to that property or its DNS. Several tiles offline at the same minute means something they share: a registrar, an account, a proxy, or a mistake that pointed them all at the same broken host. The response is different. Shared failures get the shared system. A single failure gets that site’s console.

Name the site out loud or in the note you keep for incidents. “Docs are offline” is a better start than “the dashboard is red.” The tile already did the naming. Use the name.

If email or SMS brought you here, open the tile anyway. Alerts can lag or repeat. The tile is the latest check DashCanopy has. How those alerts are chosen is in email versus SMS.

Confirm it in a browser

Open the saved URL in a private window so you are not looking at a logged-in session customers do not have. Three branches follow.

The page does not load for you. This is a real failure to answer, or a failure from your network that you should confirm on a second network if the result would be expensive. Then go to the host. You are done with the dashboard until a later check.

The page loads, and it is the site you expected. Wait for the next check interval before you declare the monitor wrong. Starter checks every 10 minutes, Pro every 5, Agency every minute. If the next check is online, you had a blip. Write down the time if this property takes money or signups. If the next check is still offline, the checker cannot see a URL you can see. Compare the saved URL character by character with the one that loaded. Look for http versus https, a stray path, or a host the firewall allows browsers to open and blocks other clients from requesting. Fix the URL or the allow rule. Do not “solve” this by turning the tile off and calling the site monitored.

The page loads, and it is an error, a parking page, or the wrong site, even though some status might still be success on a different URL. If the tile is offline, the checker agrees something is wrong. If you later get a 200 from a parking page, the tile can go back to online while the site is still useless. After you restore the real site, load the URL and read it. Do not stop at the color of the tile.

Degraded is not this article. Degraded means a slow success. If the tile says degraded, follow what the three states mean instead of this outage sequence.

At the host, in a short order

You are in the host’s tools now. DashCanopy does not store your server logs, and it does not roll back a release. Use the host for that.

Look at the last deploy time against the time the tile changed. A failure that starts at a deploy is a deploy until proven otherwise. Roll back or fix forward using the host’s normal method. The dashboard cannot do that click for you.

If there was no deploy, look at DNS and the certificate. Expired certificates and half-finished DNS edits produce failed checks for visitors and for the monitor together. The host or DNS provider shows those dates. Bring a notebook, not a theory about traffic.

If the process is running and the URL still fails, read the application log for the error status the checker received. A 502 from a proxy and a connection timeout are both offline on the tile, and they are different repairs. Status codes are documented by MDN (HTTP status). The log is where your app says which one it emitted.

If this site reports stats or webhooks, ignore those series until the URL answers. A gap in visitors during an outage is the outage. Do not open a second incident called “traffic dropped” for the same hour.

Tell people if customers can see it

Use the status channel you already have: a status page you operate, an email list, or the support inbox. Say which property is affected, that you are looking, and what still works if you know. “The docs site is not loading; the app is up” is a useful sentence and is exactly what separate tiles make possible. A SaaS-shaped portfolio is described in monitoring the marketing site, app, and docs.

DashCanopy is not that status channel. White-label branding on Agency changes how the dashboard is presented to your team. It does not publish an incident to your customers by itself.

After it recovers

Wait for a successful check so the tile matches reality. Then write three facts: when it failed, when it answered again, and what the cause was if you found one. You do not need a formal postmortem tool for that. You need the note so next time you do not start from zero.

If you never found a cause and it recovered on its own, say so. “Unknown, recovered after one check” is an honest note. Inventing a cause trains the next incident to look for the wrong thing.

If the same tile fails again the same way, the follow-up is on the host: a health check from inside the platform, a process manager, a certificate renewal. Tightening the DashCanopy interval, by moving from Starter’s 10 minutes toward Agency’s 1 minute, shortens how long the tile can stay wrong. It does not repair the underlying fault. Buy the faster interval if you need to see the failure sooner. Still fix the fault where it lives.

Plan prices stay on the pricing page. This sequence is the same on every tier. Only the wait for the next check changes.

What not to do

Do not delete the site to clear a red tile. You will lose the reminder that it needs a repair, and you may forget to add it back.

Do not point the tile at a different website that happens to be up so the dashboard looks green. That is a false monitor. It will sit online on the day the real site dies.

Do not treat a single offline check, already recovered, as a reason to migrate hosts that afternoon. Migrate when you have a pattern or a host-level cause. One recovered blip is a note.

Questions during an offline tile

The tile flipped back to online before I opened the host. Should I keep going?

Look once at the host for a deploy or a resource alarm at that timestamp. If you see nothing and the URL loads, stop. Record the blip. Keep going only if the property is critical and the blip is part of a pattern you have already seen.

Can I acknowledge the incident inside DashCanopy?

The product’s job in this moment is the tile and, if you turned them on, email or SMS. There is not a separate incident desk you must click through before you are allowed to open the host. Go to the host.

Customers say it is down and the tile says online. Who is right?

Both can be, if they are hitting a different URL, a different region, or a logged-in path you do not monitor. Open the URL the customer named. If it fails, add or change a tile so the check covers that URL. If it loads for you, ask what they clicked. The tile is not a lie just because it measured a different request.