When your upstream provider goes down, you cannot fix the outage, but you can control what your customers hear. Confirm the incident first, assess who is affected, notify customers in plain language and promise the next update time instead of a fix time. <\/p>\n\n\n\n
Never state a cause or an estimate you cannot source. After recovery, verify independently, then close with a clear summary. This plan follows that order: confirm, assess, notify, update, verify and close. <\/p>\n\n\n\n
We are an upstream provider ourselves, so we have written it for the people who depend on providers like us.<\/p>\n\n\n\n
Your customers\u2019 sites, email and DNS may all stop answering while your own dashboards still load. The upstream provider owns the infrastructure, you own the customer relationship, and the gap between those two facts is where trust is won or lost. Understanding what is actually affected is the first job.<\/p>\n\n\n\n
A reseller level problem lives inside your account: a suspended package, a wrong nameserver, a full inode quota, a billing glitch. You can usually fix it yourself. An infrastructure level problem lives beneath your account: a failed disk, a network cut, a power event at the data center. You can only report it and wait.<\/p>\n\n\n\n
Telling the two apart early saves hours. If only one customer is affected, look at your own side first. If many unrelated accounts on the same server fail together, the cause is likely upstream. <\/p>\n\n\n\n
Check before you announce anything, because blaming your provider for your own misconfiguration costs you credibility twice.<\/p>\n\n\n\n
Upstream outages come from a short list: power failures, network or routing faults, hardware failures, software updates that go wrong, DDoS attacks and human error during maintenance. Cooling problems at a data center and fiber cuts are rarer, but they last longer when they happen.<\/p>\n\n\n\n
You will not know which one you face at the start, and you should not guess in public. The cause often becomes clear only after the provider investigates. List the possibilities for your own thinking, but tell customers only what the provider has confirmed. <\/p>\n\n\n\n
Different causes mean very different recovery times, which is exactly why a guessed cause leads to a guessed estimate, and a wrong guess is hard to retract.<\/p>\n\n\n\n
Customers experience outages in their own terms. A shop owner sees lost orders. A business owner cannot read email. A blogger sees a blank page and assumes the site was hacked. Each cares about a different part of the service, and none of them care which layer failed.<\/p>\n\n\n\n
Websites, email, DNS, databases, control panels and billing portals can fail separately or together. Email is often the most painful, because messages may bounce or queue. Customers on a shared plan, such as our shared web hosting<\/a>, usually fail together when the server does, while customers on separate servers may not. <\/p>\n\n\n\n Think about the whole customer experience, including your own support channels if they run on the affected infrastructure.<\/p>\n\n\n\n Build a quick map. Which servers are down? Which accounts live on them? Which services are affected: web, email, DNS, databases, SSL renewal or the control panel? A simple spreadsheet, or a WHM account list sorted by server, answers the first question in minutes.<\/p>\n\n\n\n Test a sample from each affected group instead of assuming. Load a few sites, send a test email and run a DNS lookup. Some services may still work while others do not, and saying everything is down when email still works creates needless panic. Record which accounts you checked and when, because accuracy here feeds every message you send.<\/p>\n\n\n\n Be honest about what you control: your communication, your support queue, your billing decisions and your own records. You do not control the data center, the network or the repair schedule. Knowing that boundary stops you from promising what only the upstream provider can deliver.<\/p>\n\n\n\n How much visibility you get depends on the plan and the provider, so read what yours includes. Our master reseller hosting<\/a> and budget reseller plans<\/a> differ in what they offer, and our reseller features<\/a> page lists the details. <\/p>\n\n\n\n Neither gives a reseller control of the underlying facility, and no honest provider can claim otherwise. Ask each provider in writing what visibility and escalation your plan includes.<\/p>\n\n\n\n Confirm before you announce. Check monitoring and provider channels, work out whether one server or many are affected, open a detailed upstream ticket, record the start time and impact, and say nothing about cause or recovery that you cannot source. The first thirty minutes set the tone for everything after.<\/p>\n\n\n\n Use more than one signal. An external uptime monitor, a manual test from a different network and the provider\u2019s status page or notices together give a reliable picture. A single failed check can be a problem on your own network, so two independent confirmations are a good minimum.<\/p>\n\n\n\n If your provider has a status page or an announcement channel, read it before opening a ticket, since the incident may already be posted. <\/p>\n\n\n\n Not every provider publishes one, so ask yours where incident notices appear before you ever need them. Compare the timestamps from your monitor with the provider\u2019s notes, because they may differ by several minutes.<\/p>\n\n\n\n Find the scope early. Test accounts on different servers, in different locations and across different services. If one server fails, the fix is probably a server level repair. If several servers or a whole location fail, the network or the facility is more likely involved.<\/p>\n\n\n\n Scope shapes your message and your urgency. A single server outage affects a known list of customers, so you can notify them directly. A multi server event may affect everyone, so you will want a public notice as well. Write down what you tested and what you saw, because the provider will ask for exactly that.<\/p>\n\n\n\n A good ticket saves everyone time. Include the affected server names or IP addresses, the first time you noticed the problem, the symptoms, such as timeouts or connection refused, and what you have already tested. Add traceroute or ping results if you can.<\/p>\n\n\n\n State the business impact in one line and the urgency honestly. Do not write a story or add anger, because a calm, specific ticket gets read faster than a long complaint. Use every emergency channel your provider offers, and note the ticket number, since you will quote it to customers. Our support runs 24\/7, and a clear ticket still beats a vague one.<\/p>\n\n\n\n Start a timeline immediately. Record when the first alert fired, when you confirmed the problem, when you opened the ticket and every update afterward, all with time zones. Memory distorts quickly under stress, and timestamps will matter when customers ask for credits.<\/p>\n\n\n\n Note the known impact as well: which servers, how many accounts, which services. Record what you do not know yet, too. Keep one shared document so everyone on your team sees the same facts. If you work alone, a plain text file with timestamps is enough. You will use this record for customer updates and for the review afterward.<\/p>\n\n\n\n The temptation to say something reassuring is strong. \u201cIt is a power issue and will be fixed within the hour\u201d sounds helpful. If it turns out to be wrong, you have lost more trust than silence would have cost. State only what your provider or your own tests have confirmed.<\/p>\n\n\n\n Use careful language: \u201cWe have confirmed that servers in one location are unreachable. Our provider is investigating. We do not yet have a cause or a recovery estimate.\u201d That sentence is honest, specific and calm. Customers forgive uncertainty far more readily than they forgive a promise that fails. Train your whole team to use the same wording, so a hurried reply on chat does not contradict the official notice.<\/p>\n\n\n\n Tell them quickly that you know, what is affected, what you know and do not know, and when you will update them next. Keep the language plain and the tone steady. A short honest message in the first fifteen minutes beats a polished one an hour later.<\/p>\n\n\n\n Speed matters more than polish. A two line message saying you are aware of the problem and investigating stops customers from wondering whether you noticed. Silence makes them assume the worst and flood your inbox with the same question.<\/p>\n\n\n\n Post it where customers will look, such as your status page, a banner on your homepage and a social media account. Then send it by email if email is not affected. The first message does not need details. It needs to exist. Use the same wording in every channel so customers see one story, and send a copy to your own team so everyone repeats the same facts.<\/p>\n\n\n\n Describe the effect in words customers use: your website is not loading, email is delayed, the control panel cannot be reached. Avoid terms like BGP, packet loss or kernel panic unless you explain them. A customer should be able to read the message and know whether their own site is involved.<\/p>\n\n\n\n Be specific about scope. \u201cWebsites hosted on servers in one data center are affected\u201d beats \u201csome services are degraded.\u201d Name what still works if that helps, such as billing and support. Precise language shows control even when the problem itself is outside your hands. If you do not yet know the scope, say that, and promise to narrow it down in the next update.<\/p>\n\n\n\n Split your message into two short parts: what we know and what we are still checking. Under the first, list only confirmed items, such as which servers are down and when it began. Under the second, list the open questions, such as cause and recovery time.<\/p>\n\n\n\n This format protects you. If the cause turns out different from what you hoped, you never claimed otherwise. It also teaches customers to trust your updates, because they see the line between fact and guess stay in the same place. <\/p>\n\n\n\n Resist the urge to move items across before the evidence arrives. When something does move from unknown to known, say so in the next update so customers can see the picture sharpen.<\/p>\n\n\n\n Always close with the time you will write again, and keep that promise. \u201cOur next update will be at 14:30 UTC, even if nothing has changed\u201d gives customers a clock to rely on. A promised update time costs you nothing, while a promised fix time can cost you a great deal.<\/p>\n\n\n\n Pick an interval you can sustain, usually thirty minutes at the start and an hour once things settle. If you have nothing new, say so. \u201cNo change since the last update; the provider is still investigating\u201d is a real update. Customers value being kept informed even when the news is the same.<\/p>\n\n\n\n Tell customers what helps. Suggest they avoid changing DNS, restoring backups or moving hosts during the outage, since those actions can create new problems. Ask them not to open duplicate tickets, and point them to your status page for live news.<\/p>\n\n\n\n Tell them what they can do usefully: notify their own clients, switch a payment page or phone line, or prepare a holding message. Be careful with advice that could cause harm. <\/p>\n\n\n\n If you are unsure whether an action is safe, say wait. A fresh mistake during an outage is harder to fix than the outage itself. A short list of dos and don\u2019ts at the bottom of every update keeps the advice consistent.<\/p>\n\n\n\n Choose one place where the latest word always lives, usually a status page, and link to it from every message. Email and social posts then point to the same source. Customers stop hunting through threads for the newest information.<\/p>\n\n\n\n Host that page away from the affected infrastructure. A status page on the same server that is down helps nobody. A free external status service or a page on a separate provider works well. Keep the wording identical to what you send elsewhere, and mark each entry with its time. <\/p>\n\n\n\n Add a short subscribe option if your tools allow it, so customers who want push updates can have them without writing to support. Keep old incidents visible for a while, since a public history shows that you report problems openly.<\/p>\n\n\n\n Write the plan before you need it. Define severity levels, prepare templates, agree how you and your upstream provider exchange updates, set a schedule, automate what you can and keep a timestamped log. During an outage you will be tired and stressed, and a prepared plan removes the guesswork.<\/p>\n\n\n\n Define three or four levels. A minor level might cover a brief slowdown affecting a few accounts. A major level covers a server down. A critical level covers many servers, data loss risk or a long outage. Each level sets who is notified, how often and through which channels.<\/p>\n\n\n\n Base the level on customer impact, not on how alarming the cause sounds. A short outage on a busy shop can matter more than a long one on a dormant site. Review the levels with your team and adjust them after each real incident, since your first draft will miss something.<\/p>\n\n\n\n Prepare templates for the first notice, an ongoing update, a restoration notice and a post incident summary. Include blanks for the time, scope and next update time. A first notice might read: \u201cWe are aware that websites on some servers are unreachable. We are investigating with our infrastructure provider. We will update you by [time].\u201d<\/p>\n\n\n\n Write versions for email, your status page and a support ticket reply. Keep them short, calm and free of excuses. Store them where the whole team can find them in seconds. Test them on a quiet day, because a template that confuses you at noon will confuse you more at midnight.<\/p>\n\n\n\n Agree how information flows before an incident. Know which channels your provider uses for incident notices and which contact handles emergencies, and test that those details work. Our end user support<\/a> runs 24\/7, and any provider\u2019s escalation path is only useful if you have it in advance.<\/p>\n\n\n\n Do not pass raw provider messages straight to customers. Translate them: confirm the facts, remove jargon and add what it means for the customer. Ask your provider whether you may quote their updates, and credit them honestly. <\/p>\n\n\n\n Agree who speaks to customers about what, so you do not both send conflicting statements. Where escalation options differ between providers, describe only the ones you have verified in writing.<\/p>\n\n\n\n Decide how often you will update before the incident. Thirty minutes works for the opening hour of a serious outage, then hourly, then every few hours for long events. Say the schedule in your first message and stick to it. Assign one person to own the timing and set a timer.<\/p>\n\n\n\n Be careful not to over promise. An update every ten minutes sounds responsive but burns your team\u2019s time and says nothing new. Fewer, reliable updates beat many empty ones. <\/p>\n\n\n\n If your provider updates slowly, tell customers your own schedule anyway and mention that updates depend on the information you receive.<\/p>\n\n\n\n WHMCS includes tools you can use during incidents, such as announcements, network issue notices and mass email to selected client groups, though the exact features depend on your version and setup. A free WHMCS license<\/a> comes with our reseller plans, so many of our customers already have these tools in place.<\/p>\n\n\n\n Check that mass mail and notices will actually work during an outage. If your WHMCS or mail server runs on the affected infrastructure, notifications may never leave. Use a separate system or a backup email route for incident messages, and test it regularly. Automation saves time only if it survives the event.<\/p>\n\n\n\n Keep a private timeline separate from the public updates. Log every observation, test result, provider message, customer complaint and decision, with times. Note who said what. This log is your memory when the incident ends and the questions begin.<\/p>\n\n\n\n It also supports credit decisions, provider disputes and your post incident review. Write entries as you go, not afterward. Short lines with times are enough. A timeline that exists is worth far more than a perfect one you meant to write. <\/p>\n\n\n\n Give one person the job of scribe during a serious incident, so the people fixing and communicating are not also trying to remember the order of events. Keep the log until any disputes are closed.<\/p>\n\n\n\n Stay calm, acknowledge the frustration, explain the dependency honestly and refer to your published terms. Handle credits and refunds by a consistent rule, not by who shouts loudest, and escalate real cases to someone with authority. Angry customers usually want to feel heard first.<\/p>\n\n\n\n Start by agreeing with the part that is true. \u201cI understand your site is down and that this is costing you business\u201d costs nothing and calms most conversations. Do not rush into explanations before the customer feels heard. A defensive opening turns a worried customer into an angry one.<\/p>\n\n\n\n Avoid scripted apology language that sounds like it came from a form. One genuine sentence beats three polished ones. Then move to facts: what you know, what you are doing and when the next update arrives. <\/p>\n\n\n\n Customers can tell the difference between sympathy and procedure. If a customer is very upset, offer a phone call rather than another email, and stay calm even if they do not.<\/p>\n\n\n\n You can say your infrastructure partner is investigating without saying it is their fault and not yours. \u201cThe servers hosting your site are offline, and we are working with our data center provider to restore them\u201d is accurate and owns the relationship. Customers bought from you, and you are responsible for the service.<\/p>\n\n\n\n Pointing at the upstream provider sounds like an excuse. Describing the dependency as part of how the service works sounds like transparency. <\/p>\n\n\n\n We are an upstream provider ourselves, and we would rather resellers speak plainly than hide behind us. Own the message, share the facts and let customers judge you by how you handled it, not by whose servers failed.<\/p>\n\n\n\n Some customers cannot wait: a store during a sale, a clinic booking system, a launch day. Ask what they need most and see whether a workaround exists. A temporary landing page on separate hosting, an email forwarding change or a cached static copy might reduce the damage. <\/p>\n\n\n\n Some CDNs can serve cached pages when the origin is unreachable, and our CloudFlare CDN<\/a> option is one place to check, though what it keeps online depends on the setup.<\/p>\n\n\n\n Be honest about what you cannot do. For customers whose sites truly cannot go down, a single server is a risk. A second environment, such as a VPS<\/a> or dedicated servers<\/a>, ideally at a separate provider or location, gives real redundancy. Raise that after the incident, not during it.<\/p>\n\n\n\n Point to your published terms calmly. Quote what they say about uptime, maintenance, outages beyond your control and credits. Do not invent rules during the incident, and do not hide behind fine print either. <\/p>\n\n\n\n Explain the policy in plain words and offer to answer questions. Link the exact clause so the customer can read it for themselves, and avoid quoting it as a weapon.<\/p>\n\n\n\n Check your own terms against your upstream provider\u2019s. If you promised more than your provider promises you, you carry the gap. Fix that mismatch before the next outage, because it is far cheaper to adjust a policy than to pay for a promise you cannot keep.<\/p>\n\n\n\n Decide your rule in advance: what qualifies for a credit, how it is calculated and how a customer asks for it. Apply it the same way to every customer in the same position. Case by case exceptions under pressure invite complaints from everyone who received less.<\/p>\n\n\n\n Check the facts first with your timeline: when the outage began, when service returned and which accounts were affected. A credit based on real figures is easy to defend. Remember that the credits you give may be larger than the credits your provider gives you, so understand that cost before you promise generosity. <\/p>\n\n\n\n A modest credit given quickly often satisfies more customers than a larger one fought over for weeks.<\/p>\n\n\n\n Some cases need a manager or owner: a customer threatening to leave, claiming large losses or raising a legal threat. Set clear triggers for escalation and make sure the senior person sees the whole timeline and the customer\u2019s messages, not just a summary.<\/p>\n\n\n\n Give the customer a name and a time for the next contact. \u201cOur owner will call you by 4 pm\u201d is better than \u201csomeone will be in touch.\u201d Keep the tone steady and the claims accurate. Do not admit liability or deny it in the heat of the moment, and seek legal advice for serious claims. <\/p>\n\n\n\n Write down the promises made on any call, and send them to the customer afterward so both sides remember the same thing.<\/p>\n\n\n\n Restored does not mean recovered. Confirm that services work for real, tell customers plainly what is back and what may still be slow, check the important functions yourself, and explain what happened once you have sourced facts. Close the loop so customers can stop worrying.<\/p>\n\n\n\n A provider saying \u201cresolved\u201d is a claim to verify, not the end of the incident. Check your own monitors, load sample sites from different networks and test email, DNS and logins. <\/p>\n\n\n\n Wait for a stable period before you declare the incident over, because services sometimes fail again shortly after they return.<\/p>\n\n\n\n Many operators wait for fifteen to thirty minutes of steady results. Choose a period that fits your service and write it down. Declaring victory too early and then going down again damages trust more than the original outage did. <\/p>\n\n\n\n Keep the incident open in your own records until the quiet period passes and every check is green.<\/p>\n\n\n\n Send a clear restoration notice: services are responding again, the time they came back and what customers should check on their side. Say \u201crestored\u201d only for what you verified. If email is still queued, say email is still catching up.<\/p>\n\n\n\n Update the status page first, then send the message through your usual channels. Thank customers for their patience in one sentence, without grovelling. Make clear that you are still monitoring and will say if anything changes. <\/p>\n\n\n\n Keep it short, since people want to get back to work. Include a line telling customers how to report anything that still looks wrong, and mention where the full summary will appear if one is coming.<\/p>\n\n\n\n Go through a checklist. Load key sites and admin pages. Send and receive test email. Check DNS resolution and that nameservers respond. Confirm databases connect, SSL certificates load and scheduled tasks resumed. Check the control panel and the billing portal too.<\/p>\n\n\n\n Look for the quieter problems: queued email that never sent, cron jobs that missed their run, failed backups or stalled payments. Sample accounts from every affected server, not just the easy ones. <\/p>\n\n\n\n A site that loads but cannot reach its database is still down for the customer. Run the same checklist on a staging or test account first, so you know what a healthy result looks like before you inspect customer sites.<\/p>\n\n\n\n After a big outage, servers often run slowly while caches rebuild and queues clear. Tell customers to expect this, and say how long you think it will last only if you have good reason. Otherwise say you are monitoring and will report.<\/p>\n\n\n\n Be direct about data. If recent changes may be missing because of a restore, or if backups were affected, say what you know and what you are still checking. Customers prefer a hard truth now over a nasty surprise later. <\/p>\n\n\n\n Ask them to report problems, and give them an easy way to do it. Keep an eye on the support queue for a few days afterward, since delayed problems often show up as tickets before they show up on a monitor.<\/p>\n\n\n\n When the facts allow, publish a short summary: what happened, when, who was affected, how it was resolved and what is changing. Use the provider\u2019s root cause only if they have given one in writing. If they have not, say the cause is not yet confirmed.<\/p>\n\n\n\n Not every incident needs one. A brief blip may deserve a line in an update. A long or serious outage deserves a proper summary, usually within a few days. Keep it factual, skip the jargon and avoid blaming individuals. <\/p>\n\n\n\n Customers do not expect perfection. They expect honesty and some evidence that you learned. Publish it in the same place as your incident updates, so people can find it without asking.<\/p>\n\n\n\n Hold a short review within a week. Look at the timeline: how quickly was the incident detected, confirmed and announced? Were the messages clear? Did updates arrive on time? Which questions kept coming back? What did customers say afterward?<\/p>\n\n\n\n Update your templates, severity levels and contact lists from what you learned, and share the review with your upstream provider so they can improve too. Ask them what they changed. <\/p>\n\n\n\n A written follow up closes the loop, and it gives you something concrete to point to the next time a customer asks what has been done.<\/p>\n\n\n\nIdentifying the Services and Accounts Affected<\/h3>\n\n\n\n
Understanding the Reseller\u2019s Control and Limitations<\/h3>\n\n\n\n
What Should a Hosting Reseller Do Immediately After Detecting an Upstream Outage?<\/h2>\n\n\n\n
Confirming the Incident Through Monitoring and Provider Updates<\/h3>\n\n\n\n
Checking Whether the Problem Affects One Server or Multiple Services<\/h3>\n\n\n\n
Opening an Upstream Support Ticket With Useful Diagnostic Details<\/h3>\n\n\n\n
Recording the Incident Start Time and Known Impact<\/h3>\n\n\n\n
Avoiding Unverified Causes and Recovery Promises<\/h3>\n\n\n\n
What Should You Tell Customers When Your Upstream Provider Is Down?<\/h2>\n\n\n\n
Acknowledging the Outage Clearly and Promptly<\/h3>\n\n\n\n
Explaining the Confirmed Impact in Plain Language<\/h3>\n\n\n\n
Separating Verified Facts From Information Still Under Investigation<\/h3>\n\n\n\n
Providing the Next Update Time Without Promising a Fix<\/h3>\n\n\n\n
Explaining What Customers Should and Should Not Do<\/h3>\n\n\n\n
Maintaining One Reliable Source for Incident Updates<\/h3>\n\n\n\n
How Can You Build an Effective Hosting Outage Communication Workflow?<\/h2>\n\n\n\n
Classifying Incidents by Severity and Customer Impact<\/h3>\n\n\n\n
Preparing Email, Status Page and Support Ticket Templates<\/h3>\n\n\n\n
Coordinating Updates Between the Reseller and Upstream Provider<\/h3>\n\n\n\n
Setting a Realistic Communication Schedule<\/h3>\n\n\n\n
Automating Notifications Through WHMCS or Other Support Tools<\/h3>\n\n\n\n
Keeping Internal Incident Notes and a Timestamped Timeline<\/h3>\n\n\n\n
How Should You Respond When Customers Demand Immediate Fixes or Compensation?<\/h2>\n\n\n\n
Acknowledging Customer Frustration Without Becoming Defensive<\/h3>\n\n\n\n
Explaining Technical Dependencies Without Shifting Blame<\/h3>\n\n\n\n
Handling Urgent Business-Critical Customer Requests<\/h3>\n\n\n\n
Referring to Published Service-Level Agreements and Policies<\/h3>\n\n\n\n
Evaluating Service Credits and Refund Requests Consistently<\/h3>\n\n\n\n
Escalating Complaints That Require Management Attention<\/h3>\n\n\n\n
What Should You Communicate When the Upstream Service Is Restored?<\/h2>\n\n\n\n
Confirming Recovery Through Independent Monitoring<\/h3>\n\n\n\n
Notifying Customers When Services Are Available Again<\/h3>\n\n\n\n
Checking Websites, Email, DNS and Other Affected Services<\/h3>\n\n\n\n
Explaining Any Remaining Performance or Data Issues<\/h3>\n\n\n\n
Publishing a Post-Incident Summary When Appropriate<\/h3>\n\n\n\n
Reviewing the Incident to Improve Future Communication<\/h3>\n\n\n\n