UltaHost Down for Days: What to Do When Your Host Goes Dark

When a host goes dark for days, your job is damage control in this order: prove where the outage is, get a copy of your site from an off-host backup, put up a temporary page so customers see something, tell your own clients before they tell you, and start a migration in parallel. Waiting on a silent status page is not a plan.

What happens when a budget host goes dark

A host goes dark when two things break at once: the infrastructure and the communication. Sites return 500 errors or time out. The status page still says "All systems operational." Tickets get an auto-reply and nothing else. Live chat queues never move. Customers find out from the public Twitter/X thread, not the company.

That is the pattern reported by UltaHost customers during the multi-day August 2026 outage: sites offline, no ETA, and a support queue that stopped answering while the hours stacked up. The technical failure was bad. The silence is what turned it into a business problem.

Here is why. If your host says "storage array failure, estimated 6 hours, restore from snapshot underway," you can make decisions. You tell clients. You buy time. You wait. If your host says nothing, you have to assume the worst case — that your data may not come back — and act on that assumption while the clock runs. Silence forces you to spend money and hours you might not have needed to spend.

That cost is real. According to Gartner's widely cited estimate, the average cost of IT downtime is about $5,600 per minute (2014). For small businesses the number is smaller but still ugly — we broke down the real financial impact of website downtime at $137 to $427 per minute in lost revenue, lost trust, and SEO damage.

What to do in the first four hours

Work in this order. Do not skip to migration first — you need proof and a backup before you touch anything.

1. Confirm the outage is theirs, not yours. Check the site from a phone on cellular data. Check a second site on the same host. Run a third-party check (downforeveryoneorjustme, UptimeRobot, or a colleague in another city). If every site on that server is down, it is the host.

2. Screenshot everything. The status page. The timestamp. Your unanswered ticket. Your billing page showing an active plan. If you later want a refund, a chargeback, or an SLA credit, you need evidence with times on it. Providers quietly update status pages after the fact.

3. Get a copy of your site from somewhere off that host. Cloud backup service, your local dev copy, your Git repo, a client's old export — anything. This is the single step that decides whether you have a bad week or a catastrophe. If your only backup lives on the same server that is down, you have no backup. Our WordPress backup strategy guide covers the 3-2-1 rule in detail.

4. Publish a holding page. You control your domain's DNS (usually at your registrar, not your host). Point the A record at a cheap static page: "We're experiencing a hosting outage. Call us at [number] or email [address]." A working phone number beats a dead site. This takes 20 minutes and saves leads.

5. Tell your clients before they call you. One short email: what happened, that it is your host and not their site, what you are doing, when you will update them next. Then actually send the next update. Agencies that communicate during outages keep clients. Agencies that go quiet lose them — for the exact same reason you are angry at your host right now.

6. Start the migration in parallel. Do not wait for the outage to end to begin evaluating a new home. If the host comes back, great, you migrate calmly. If it doesn't, you already have somewhere to land. Our WordPress migration guide walks the full process.

The agency that stopped absorbing outages

Fresh Ground Thinking is a full-service creative agency running more than 100 WordPress sites for clients. The team did not set out to be a hosting company. It happened anyway.

How the pain showed up. Sites were scattered across whatever host each client had signed up for years earlier. Every outage, every failed update, every "my site looks weird" email landed on the agency — because the agency built the site, so the agency owned the problem in the client's mind. Nobody was watching the fleet as a whole. Problems got discovered by clients, which is the most expensive way to discover them.

The team was burning 60+ hours a month just keeping the lights on. That is a third of a full-time person, unbilled, spent on server babysitting instead of the creative work the agency actually sells. It is the same trap we describe in why your developer hates your hosting — smart people doing ops work they were never hired to do.

The diagnosis. Three separate issues, not one:

• No single view. With sites spread across many providers, nobody could answer "is everything up right now?" without checking each one.
• No proactive alerting. The monitoring was human beings and client emails.
• No accountable support path. Each host had its own queue, its own hours, its own excuses. Escalation meant starting over every time.

The fix. Consolidate the fleet onto one managed platform with 24/7 monitoring, one support relationship, and one accountable owner for uptime. Updates, backups, and security handled at the platform level instead of site by site.

The outcome. Fleet upkeep dropped from 60+ hours a month to under 5 hours. And per the Fresh Ground Thinking case study, no client site has gone down in a year.

That is the real contrast with an UltaHost-style blackout. It is not that good hosts never have incidents — every provider has them. It is that somebody is watching, somebody tells you, and somebody is accountable when it happens.

Budget host vs managed host: what actually differs during an incident

The price gap is real, and it is the whole argument. A $10/mo plan is cheap because nobody is watching it. You are the monitoring. You are the incident response. You are the communication layer. When you price your own hours honestly, the math flips fast — that is the case we lay out in what managed WordPress hosting actually includes.

How to judge a host before you sign

Use this five-question screen on any provider, including us. Ask before you move, not after.

1. Is there a written SLA, and what does it actually promise? Not "99.9% uptime" in marketing copy — the real document, with the credit terms and the exclusions. If you cannot find it in two minutes on their site, that tells you something. Ours is at /sla.

2. How will you tell me during an incident? Email? Status page? Dashboard banner? Ask for the specific mechanism. "Check our status page" is a weak answer if the status page is manually updated by the same team that is busy firefighting.

3. Who answers, and how fast? Ask for the support commitment in writing. TopSyde's is under 2 hours during business hours, and you talk to a senior developer, not a script. Note that human support hours and 24/7 monitoring are two different things — any host that blurs them is hiding something.

4. Where do backups live? The correct answer is "off the server your site runs on," with a restore you can trigger yourself. Ask them to describe the restore process out loud.

5. What happens on a zero-day? A host that patches at the network level protects you before you can update. We covered what that looks like in how managed hosts handle WordPress zero-days. A host with no answer here is leaving you exposed between the disclosure and your next maintenance window.

Your go-dark readiness checklist

Do these now, while nothing is on fire. Each one takes under an hour.

• Off-host backup running weekly. Verify it by actually restoring one site to a local environment. An untested backup is a rumor.
• Domain registrar separate from hosting. If your host also controls your DNS and your host is down, you cannot even post a holding page. Split them.
• Independent uptime monitoring. Do not rely on your host to tell you your host is down. Set up your own checks — see our WordPress uptime monitoring guide for tools and alert thresholds.
• A pre-written outage email. Draft it today. Fill in the blanks during the incident. You will not write well at 2 a.m.
• A holding page ready to deploy. A single static HTML file with your phone number and email, sitting in a repo, ready to point DNS at.
• Your host's SLA saved as a PDF. Terms change. Save the version you agreed to.
• A named fallback host. Know where you would go. Have an account open, even on the smallest plan.
• Client contact list current. Exported, offline, not living inside a CRM hosted on the same infrastructure.

For stores, add one more: know your checkout failure mode. A WooCommerce outage during a sale weekend is a different order of magnitude than a brochure site being down — that is why we argue WooCommerce belongs on managed hosting, not shared.

The honest takeaway

Outages happen everywhere. Hardware fails, data centers flood, a bad config ships on a Friday. Nobody sells zero incidents, and you should not believe anyone who does.

What you are actually buying with a better host is information and accountability. Somebody watching around the clock. A written commitment you can hold them to. A human who answers in under 2 hours during business hours and can actually fix the thing. And backups that live somewhere your host's bad day cannot reach.

If you are managing sites for clients and currently absorbing every outage yourself, look at the agency hosting side of what we do or the full pricing breakdown. And if you want the receipts before you talk to anyone, the case studies are all published with real numbers.

Frequently Asked Questions

What should I do if my host is down and support isn't responding?

Confirm the outage from an outside network, screenshot the status page and your unanswered ticket with timestamps, then pull a site copy from an off-host backup. Point your domain's DNS at a temporary holding page with your phone number, and email affected clients before they email you.

Can I get a refund or SLA credit for a multi-day outage?

Sometimes, but only if you documented it. Most SLAs require you to request credits in writing within a set window, and credits usually apply to hosting fees only — not your lost revenue. Save timestamped screenshots and ticket numbers, then cite the specific SLA clause in your request.

How do I move a WordPress site off a host that's completely offline?

If the server is unreachable, you cannot export from it — you restore from an off-host backup instead. That is why an independent backup copy matters more than anything else on the checklist. If you have a recent database dump and wp-content folder, a new host can rebuild the site without the old one ever coming back.

Is a 99.9% uptime guarantee good enough?

99.9% allows about 43 minutes of downtime per month, which is fine for most brochure sites. The number matters less than the terms around it: what counts as downtime, who measures it, what the credit is, and whether the provider actually tells you when something breaks. Read the SLA before you judge the percentage.

Should I keep backups with my hosting provider?

Keep them there and somewhere else. Host-side backups are fast and convenient for routine restores, but they are useless in exactly the scenario you are worried about — the host being unreachable. Follow 3-2-1: three copies, two media types, one off-site.

Marcus Webb

DevOps & Security Lead

12+ years DevOps, Linux & cloud infrastructure certified

Marcus leads infrastructure and security at TopSyde, managing the server fleet and AI monitoring systems that keep client sites fast and protected. Former sysadmin turned WordPress hosting specialist.

XLinkedIn