Site Down: Matching What You See to the Cause

This is the cross-product triage tree for a site that will not load. Kapsule runs several products, and the fastest way to find the cause is not to guess which one is at fault, but to look closely at exactly what the browser puts on the screen. Every branch below is keyed on something you can see or test yourself in under a minute, and each one rules the others out.

Work top to bottom. The first four questions eliminate most of the tree, and the branches after them are meant to be mutually exclusive: you should land in exactly one.

The Four Questions That Split The Whole Tree

Answer these before you change anything. Each one is a test you can run yourself, and each one removes whole categories of cause.

1. Is it a calm page, or an error? If a tidy page appears saying the site is paused, that is not a technical fault at all. It is a billing state, and the fix is in your account, not your code. Go straight to branch A below.

2. Does it fail on mobile data as well as on your wifi? Turn wifi off on your phone and load the site over the mobile network. If it loads on mobile data but not on your wifi, nothing is wrong with the site: the fault is your local network, your router, or a stale DNS cache on your machine. If it fails on both, the problem is real and your visitors have it too.

3. Is it one page, or every page? Try the home page, then an interior page, then a deliberately invented address such as /this-page-does-not-exist. Which of those three work, and what the invented one returns, is the single most informative test in this guide. Two branches below are decided by it alone.

4. Do you see an error, or somebody else's website? A site that will not load and a site that loads the wrong content are completely different problems. If your OLD website appears, nothing is broken: your domain is still pointed at your old host. That is branch D, and it is the most commonly misread symptom there is.

One test that is worth skipping: adding ?cachebust=1 to the address does not do what people think on our network. Our edge leaves the query string out of the cache key, so that address returns the same cached copy as before. To force a fresh answer, add a random PATH segment instead, as in yourdomain.com/anything-random-here. This is measured behaviour, not a guess, and it matters in branch H.

Step Zero: Find Out Whether It Is Us

Before you read any further, check whether the platform is reporting a problem. Our status page is public, needs no login, and updates continuously:

status.kapsulehost.com

You can also reach it from the bottom of the KPanel sidebar as System Status.

Do not read the headline alone. Find the ONE row that matches the product your site runs on, because the rows fail independently:

If your site is	Watch this row
A website or WordPress site	Web Hosting, or Managed WordPress
An app you deploy with Orbit	Kapsule Orbit
Behind our CDN	Kapsule CDN
Using our nameservers	Premium DNS
Failing only on HTTPS	SSL Certificates

An all-operational status page does not mean your site is fine. It means the shared platform is fine, which is genuinely useful: it tells you the cause is in your own account, your own configuration or your own code, and it moves you straight into the branches below. The status page reports our components, never your individual site.

For the availability of your own specific project rather than the platform, see Orbit Status Pages and Uptime Monitoring. Uptime monitoring measures reachability, not correctness: a site that returns a broken page quickly still counts as up.

A: A Calm Holding Page, Not An Error

What you see: the site does not error. A deliberately calm page loads, headed "This site is paused for now." It explains that the hosting is on hold, that nothing is lost, and it offers a button to sign in.

What it means: this is a billing state, not a technical fault. The server is healthy and is answering on purpose. No amount of clearing caches, re-pointing DNS or redeploying will change it.

What to do: sign in and settle the account. The site comes back within minutes of payment clearing, and your data was never touched. Start at Why Your Account Was Suspended, and for the full schedule of what happens on which day, What Happens If You Stop Paying.

This narrows the product too. Only a website on a hosting subscription is ever given a holding page. An Orbit project keeps serving through a payment problem on purpose, and a Cloud Server is never powered off for one. So a holding page tells you which product you are dealing with as well as which kind of problem.

The holding page is deliberately temporary as far as search engines are concerned, and it asks them not to index it. A short suspension does not throw away your rankings. Certificate validation is exempt from it, so renewals keep working and your HTTPS does not lapse while you sort the bill out.

Returning to service is not instantaneous. Paying updates your account immediately, but a background reconciler is what lifts the block on the web server, and it runs on a cycle of a few minutes. If the holding page is still there right after payment, wait a few minutes and reload in a private window before raising a ticket.

A2: You Cannot Sign In, But The Site Is Fine

What you see: the opposite of branch A. Visitors get the website perfectly normally, but you cannot get into KPanel. The login page says "Your account has been suspended. Contact support."

What it means: this is also billing, and it is the case most people misread. Several account-level suspensions never touch the websites at all: an annual invoice you pay by hand, a suspension raised by our team, and an account billed through a reseller all lock the panel while every site carries on serving. Nothing about your site will tell you this has happened, which is exactly why it is worth naming here.

What to do: settling the invoice is necessary but, on these paths, is often not sufficient on its own to restore panel access. Email support@kapsulehost.com from the account email address, say that you have paid, and ask for access to be restored. Include the invoice number.

If you were already signed in when a suspension was applied, your existing session keeps working until it expires. Being able to use the panel right now does not prove the account is in good standing. Check Billing directly rather than reading anything into still being logged in.

B: Orbit Shows A Short Line Of Raw Text Starting With `{"error":`

What you see: no styled page at all, just one short line of machine text in the browser, shaped like {"error":"..."}.

What it means: your Orbit hostname resolved and reached us correctly, and our serve path answered. The word inside that line names the cause exactly, and the three words mean three different things:

What the line says	What is actually wrong
`no_deployment`	Nothing has ever been promoted to this environment. No build has succeeded yet
`no_artifact`	A deployment is live, but the build it points at produced no files to serve
`not_found`	This hostname is not attached to any environment we serve

All three are a 404 and they are different problems, so read the word rather than the status code.

no_deployment is the one that catches people out. A failed build does NOT take a working Orbit site down. What serves is the last deployment that was successfully promoted, and a failed build never becomes that. The exception is a project whose builds have only ever failed: it has nothing to fall back on, so it serves nothing. The deploy failure email tells you which case you are in, in as many words. It either says "The previous deployment is still live", or it says "Nothing is live yet: there is no earlier deployment to fall back on, so this project stays offline until a build succeeds."

So if your Orbit site went down at the moment a deploy failed, and this was not its first ever deploy, the failed deploy is almost certainly not the cause. Carry on down this tree instead of staring at the build log. See Build Troubleshooting and Rolling Back a Deployment.

Two build failures are ours, not yours. Most failed builds are something in your code or your dependencies, and the failure screen names the category. Two categories are the platform's fault rather than yours, and they are worth recognising so you do not spend an afternoon bisecting your own commits: a build blocked by our egress policy, and our build sandbox failing underneath you. See Blocked by Our Policy and Our Build Sandbox Failed. A sandbox failure is retried once automatically before you are told about it.

A build that SUCCEEDS can also take a site down and then bring it back on its own. If you have health checks, smoke tests or a performance budget enabled, a successful deployment that fails its check is rolled back automatically and marked as failed after the fact. If your site was briefly broken and then recovered without you touching it, look at the deployment list rather than at your code.

C: Every Address Returns The Home Page

What you see: the home page loads. Interior pages also return the home page rather than their own content, and so does a deliberately invented address such as /this-page-does-not-exist, which answers with the home page instead of a 404.

What it means: this is the single-page-app fallback, and on Orbit it is deliberate for the frameworks that need it. A Vite, Create React App or Angular build is client-routed: the server has only one HTML file, and the app decides what to render from the address, so every unknown path has to be answered with that file or deep links break.

When it is correct: your app is client-routed and your router simply is not matching the address. The fault is in your front end code, not the hosting.

When it is wrong: you are not running a client-routed framework, and a wrong address is silently answering with your home page. That is worth fixing, because a broken internal link then survives every crawl and search engines treat it badly. Check the framework preset on the project: the preset you chose wins over what we detect, so an incorrectly chosen preset produces exactly this symptom. See Frameworks and Build Configuration.

The healthy behaviour for everything else: an unknown address returns your build's own 404.html if the build contains one, with a real 404 status, and our own 404 page if it does not.

D: Your Old Website Appears Instead Of The New One

What you see: something loads, and it is wrong. It is your previous website, your old host's parking page, or a "coming soon" page you do not recognise. Nothing errors.

What it means: your domain is still pointed at your old host. The request never reaches Kapsule at all, so nothing you change on our side can affect what the visitor sees. This is the most commonly misread symptom in hosting, because a working page feels like progress.

How to confirm it in one place:

For a domain registered with us, open Domains, then the domain. The card there tells you plainly which of five things is true, including "Not pointed here", which reads: "Every resolver we checked returns nameservers that are not ours, so traffic for this domain is not reaching KapsuleHost." If it says "Propagating" instead, it names how many resolvers already agree, and it finishes on its own, usually within a few hours.
For an Orbit custom domain, open the project's Domains screen. "Invalid Configuration" with a note that the name resolves somewhere else is the same finding.

What to do: change the records at whoever holds the domain, then wait. See Nameservers and Adding a Custom Domain to an Orbit Project.

These two screens answer two different questions and can disagree while both are correct. The Domains screen asks whether your nameservers are delegated to us. The Orbit screen only asks whether this one hostname resolves to our edge. A domain whose nameservers still sit at your old provider, but which has a correct record pointing one hostname at us, will show as valid on the Orbit screen and as not pointed here on the Domains screen. If you are troubleshooting a domain, look at both.

E: The Browser Cannot Find The Domain At All

What you see: the browser never reaches a server. It reports that the address could not be found or that the server IP address could not be found, and it fails identically on mobile data and on wifi, in a private window, and for other people.

What it means: the name does not resolve for anybody. There is no record to follow, so the request is not slow or refused, it simply has nowhere to go. The usual causes are a domain that expired, a domain whose nameservers were never set, a record that was deleted, or a name that was only ever typed into our panel and never created at the registrar.

What to do, in this order:

Check the domain has not expired. Open Domains and look at the domain's status. An expired domain stops resolving regardless of how healthy the hosting is, and renewing it is the only fix. Our clock is not the registry's clock: see Domain Renewal and Expiry.
Check delegation on the domain's card. "No answer" there means no resolver can find the domain at all, which usually means it is newly registered, expired, or has no nameservers set.
If you added the name to an Orbit project, check the project's Domains screen for "No DNS record found for this name yet." Adding a domain in the panel does not create anything at your registrar. You still have to publish the record it shows you.

For what each record type does, see DNS Basics and CNAME Records.

F: A Certificate Warning Instead Of The Site

What you see: the browser blocks the page with a security warning rather than loading it, saying the connection is not private. The site itself is healthy behind that warning: this is about the certificate, not the server.

What it means: either no certificate has been issued for this exact hostname yet, or the one that exists has expired, or it covers a different name than the one you typed. A very common version is that www.yourdomain.com and yourdomain.com are not both covered, so one works and the other does not. Test both spellings explicitly: if one loads and the other warns, it is a certificate and record problem for that one name, not a server problem.

For a website on hosting, do not trust the site overview screen. The overview shows a certificate as either Active or Pending, and "Pending, certificate being issued" is what it displays for an expired or failed certificate too. That is reassuring at exactly the wrong moment. Go to the site, then Security, which shows the real state: how many days the certificate has left, and a Renew now button. That screen is the honest one and it is where you should look.

For an Orbit custom domain, the panel is explicit. The project's Domains screen distinguishes between DNS being wrong, the certificate being issued right now ("DNS is correct. The certificate is being issued, which usually takes a few minutes."), and a state that is ours to fix: "Your DNS is correct. This domain is not set up on our edge network yet, which is on our side rather than something to change at your registrar." If you see that last one, press Refresh on the screen. It is not something you can fix at your registrar, and there is no setting of yours that will change it.

Trying http:// instead of https:// is a useful test on hosting, but it does not work on an Orbit custom domain. We turn on forced HTTPS the moment a custom domain is added, and attaching the first custom domain to a project also switches on a browser rule that makes browsers refuse plain http for that hostname for a year. On Orbit, both will fail together even when only the certificate is at fault, so do not read that as a bigger outage than it is.

Certificate issuance needs DNS to be correct first, so if branch D or E applies, fix that before reissuing anything. See SSL Certificates, and for a padlock that is broken rather than missing, Fixing Mixed Content Warnings.

G: A 5xx Error Page

What you see: a real HTTP error with a number in it: 500, 502, 503 or 504. The domain resolved, the certificate was accepted, and a server answered. That is a lot of the tree already eliminated.

What it means: the request reached us and the application behind it failed or did not answer in time. The number matters: a 500 is your application raising an error, a 502 and a 504 are about the process behind the web server being unreachable or too slow, and a 503 is a deliberate refusal, which on hosting is what a suspension looks like underneath the holding page in branch A.

What to do: read the number, then read your own logs. Open the site and then Logs, and look at the most recent entries: a PHP fatal error names the file and line, which identifies the plugin or the code responsible. Full detail per code is in HTTP Error Codes, and the usual application-level causes are in My Website Is Not Loading.

If this started immediately after a change you made, that change is your first suspect, and restoring is faster than debugging. See Restoring From a Backup.

H: The Site Loads But The Content Is Wrong Or Old

What you see: the site works, but it is serving something out of date: a page you deleted, an old stylesheet, a fix you deployed an hour ago that is not showing, or a broken page that you have already repaired.

What it means: you are being served a cached copy from our edge rather than a fresh answer from your site. Our CDN deliberately keeps serving the last good copy when the origin behind it is unreachable, which is usually a kindness and is occasionally confusing, because it means a working-looking site can sit in front of an origin that is actually down.

How to prove it is cache and not your site: load a random path that cannot be cached, such as yourdomain.com/anything-random-here. Do not use ?cachebust=1: our edge ignores the query string when it decides what to serve from cache, so that returns the cached copy and proves nothing. If the random path shows fresh behaviour and your real page does not, you are looking at cache. In browser developer tools, the response header cdn-cache says HIT, MISS or BYPASS, which answers the same question directly.

What to do: purge the cache. See Purging the CDN Cache. Purge any caching plugin and your site cache too, and then check in a private window so your own browser cache does not fool you. Site Caching covers the layers in order.

Bandwidth is not the cause. Our CDN bandwidth is unlimited to you: going over an expected volume never pauses your site, never removes your hostname from the edge and never silently switches you to a slower path. If your site is slow or stale, look at cache and at the site itself, not at how much traffic you have used.

What To Send Support If You Are Still Stuck

If you have worked through this and still cannot place the fault, one good message saves a day of back and forth. Include:

The exact address you are loading, with https:// and with or without www exactly as you typed it.
The exact error, copied as text rather than described. If it is a line starting with {"error":, send that line verbatim, because it names the cause.
Which branch above you landed in, and what the panel screen said.
Whether it fails on mobile data as well as wifi, and whether it fails for other people.
When it started, and what changed around then.

Email support@kapsulehost.com or open a ticket from Support in KPanel. See Opening a Support Ticket.