The 10 Support Tickets That Are Not Hosting Problems and Ready Replies for Each
Ten kinds of tickets reach hosting support constantly that the server did not cause: a broken plugin, a bad update, a cached page, a failing outside service, a wrong redirect, DNS pointing elsewhere, rejected email, wrong mail client settings, slow propagation and an SSL warning from configuration. Each one needs checking before you reply, because any of them can also be a genuine server side fault. This guide gives you a diagnostic route for each ticket and a ready reply you can adapt.
We have run support desks for over 20 years, with 24/7 support across more than 700,000 hosted websites and customers in 65+ countries. One lesson keeps repeating. The fastest tickets to close are the ones where the agent shows evidence, not the ones where the agent sounds confident.
How Can Hosting Support Teams Identify Problems Outside Their Infrastructure?
Check the server first, reproduce the problem second and read the logs third. If the hosting layer is healthy and the logs point to an application, a DNS record or an outside service, you have an answer backed by evidence. Never decide responsibility from the ticket subject line alone.
Hosting Infrastructure vs Website Application Issues
Think in layers. The hosting layer covers the network, the physical server, the web server software, PHP, the database service and the resources assigned to the account. The application layer covers the code a customer installed, such as WordPress, its plugins, its theme and its settings. A third layer sits outside both: DNS, the registrar, mail receivers and outside APIs.
The same symptom can live in any layer. A 500 error might be a crashed PHP service, which is ours, or a typo in a plugin file, which is not. The ticket looks identical until someone reads the error log.
So the first job of a support agent is sorting, not fixing. Decide which layer the evidence points to, then act on that layer.
Checking Server Status Before Assigning Responsibility
Before anything else, rule out the platform. Check monitoring for the server the account lives on, confirm that web, database and mail services are running, and look at load, disk space and inode usage. Check whether other accounts on the same server are reporting similar symptoms.
Here is the part that trips agents up. A healthy server does not mean a healthy account. An account that has hit its own resource limit will show errors while everything else looks green, and that counts as a hosting matter because limits are part of the plan. Check the account level numbers too, not only the server level ones.
Write down what you checked and when. That note becomes the evidence in your reply.
Using Logs and Reproducible Tests to Find the Cause
The error log usually names the culprit. Look for the path in the failing line. A path inside a plugin folder points to the plugin. A path inside the PHP configuration or the server runtime points to us.
Then reproduce the problem yourself. Load the page, check the response headers and test a plain PHP file placed in the account. If the plain file works and the site fails, the server is running PHP correctly and the fault sits in the site. Test from a second network when you can, since a problem that only appears from one location is rarely the server.
Keep the reproduction steps short enough to paste into a reply. Customers trust a result they can repeat.
Explaining Support Boundaries Without Blaming Customers
Customers do not know where hosting ends and their website begins, and they should not have to. Your job is to draw that line gently. Say what you checked, what it showed and what that means for next steps.
Compare two replies. One says “this is a plugin problem, not ours.” The other says “the server is running normally, and the error log points to a plugin, so here is how to test that.” Both state the same fact. Only the second one leaves the customer with something to do.
One more honest point. Support boundaries differ between plans and providers, so state yours plainly instead of implying every issue is covered or every issue is excluded.
Which Website and WordPress Issues Are Not Always Hosting Problems?
Plugin or theme breakage, update errors, cached pages, failing outside services and bad redirects are the five most common. Each one arrives as “my website is down,” and each can be proven from logs rather than guessed. Note the phrase “not always”: every one of these can occasionally trace back to the server.
Ticket 1: A WordPress Plugin or Theme Broke the Website
The customer reports a white screen or a message about a critical error right after installing or updating a plugin. This is the most common ticket on the list. The error log typically shows a fatal error with a file path inside the plugins or themes folder.
Confirm the server is healthy, find the offending path and tell the customer which plugin it names. If they can reach their files through the File Manager in cPanel, which is part of what comes with our shared web hosting plans, renaming that plugin folder disables it and usually brings the site back at once.
READY REPLY
Hi [Name],
Thanks for reporting the error on [domain]. We checked the server and it is running normally, with no outage or resource problem on your account.
The error log shows a fatal error coming from the plugin [plugin name], first logged at [time]. That points to a conflict inside the site rather than a server fault.
Please rename the folder wp-content/plugins/[plugin name] using File Manager, then reload the site. If the site returns, that plugin is the cause, and you can reinstall an earlier version or contact its developer. If nothing changes, reply with the exact error text and we will keep investigating.
Kind regards, [Agent name]
Ticket 2: A Website Update Caused an Application Error
This looks like Ticket 1, but the trigger is a core update, a PHP version change or a database upgrade prompt that never finished. Ask what changed and when. Check the account for a recent PHP version switch, since a site built for an older release can fail on a newer one.
Here the hosting side is partly involved if we changed something, so check your own change log before replying. If the update was run through an installer such as Softaculous, note which version it moved from and to. A restore from a backup taken before the update is usually the quickest safe route.
READY REPLY
Hi [Name],
Thanks for the details about [domain]. We reviewed the account and found no server fault. Our records show [PHP version or update detail] changed on [date], which matches when the errors began.
The error log shows [short error message], which comes from the site code and not from the server. There are two safe options. You can set PHP back to [previous version] from your control panel while the site is updated for compatibility, or we can help you restore a backup from before [date].
Tell us which you prefer and we will guide you through it. If you choose the PHP change, please let us know whether the error disappears.
Kind regards, [Agent name]
Ticket 3: The Website Displays a Cached or Outdated Version
The customer says edits do not show up. Caches stack: the browser, a caching plugin, the server and often a CDN. Request the page with a cache bypassing method and compare the response with what the customer sees. If the fresh response is correct, the server is serving the right files.
If the site sits behind a CDN such as CloudFlare, the stale copy may be held at that edge, and only a purge there will clear it. Ask which layers are in use before telling the customer to clear anything.
READY REPLY
Hi [Name],
Thanks for letting us know. We requested [domain] directly from the server and it is returning your latest version, last changed [date or time]. That means the older page you see is being held in a cache.
Please try these in order. First, open the page in a private window. Second, clear the cache in your caching plugin, [plugin name]. Third, if you use a CDN, purge its cache from its dashboard.
If the old version is still showing after that, send us a screenshot and the exact address and we will look further.
Kind regards, [Agent name]
Ticket 4: A Third Party API or External Service Is Failing
Payment gateways, shipping calculators, map widgets, social feeds and email APIs all live outside the hosting account. The symptom is usually a part of the site that fails while the rest works. The error log often shows a timeout or a refused connection to an outside address.
Test whether the server can reach that service. If it can, and the service status page reports an incident, you have your answer. If the server cannot reach it, check firewall rules on our side before blaming the provider, because an outgoing block can be ours.
READY REPLY
Hi [Name],
Thanks for the report about [feature] on [domain]. We tested the connection from your server to [service name] at [time] and [result of test].
The error log shows [short log line], which means the request to the outside service is not completing. [Service name] currently lists [status page finding] on its status page.
We suggest checking that your API keys in the site settings are current and contacting [service name] support with the time of the failure. If you would like us to look at anything on the server side again, reply with the time of your next failed attempt.
Kind regards, [Agent name]
Ticket 5: A Website Redirect or Configuration Rule Is Incorrect
The classic version is a redirect loop, where the browser reports too many redirects. Causes include conflicting rules in the .htaccess file, a mismatch between the site address and the home address in WordPress, a plugin forcing HTTPS while something else forces HTTP, or a CDN setting that disagrees with the origin.
Check the response headers by following the redirect chain from the command line. The chain shows where the loop starts. A clean chain from the server with a loop only in the browser points back to a cache or a CDN rule.
READY REPLY
Hi [Name],
Thanks for reporting the redirect error on [domain]. We followed the redirect chain and found that [address A] sends visitors to [address B], which sends them back, so the page never loads.
This comes from a rule in the site setup, either in the .htaccess file or in your site address settings. The server itself is responding correctly.
Please rename the .htaccess file to .htaccess.old and reload the site. If it loads, the rule inside that file is the cause, and we can help you review it. If it does not, check the site address and home address settings for [domain] and send us what you find.
Kind regards, [Agent name]
Which DNS and Email Issues May Originate Outside the Hosting Server?
Wrong nameservers, rejected email, bad mail client settings, slow propagation and SSL warnings all sit at the edge of the hosting service. The registrar, receiving mail servers and the customer’s own devices play a part in each. They are still the tickets where we are most likely to share some of the responsibility, so check our side first.
Ticket 6: The Domain Points to the Wrong Nameservers or IP Address
The customer moved hosting or bought a domain elsewhere, and the site shows an old page or an error. Look up the nameservers and the address records the domain currently returns. Compare them with what the account on our server expects.
The fix usually happens at the registrar, where we may have no access. State clearly what the correct values are, where to change them and what to expect afterward.
READY REPLY
Hi [Name],
Thanks for contacting us about [domain]. Your hosting account is active and the website files are in place. A lookup shows the domain is currently using the nameservers [current nameservers] and pointing to [current IP address], which is not this server.
To connect the domain to your hosting, please sign in at your domain registrar and set the nameservers to [our nameservers], or set the address record to [correct IP address]. If you are not sure where your domain is registered, we can help you find out.
Once you have made the change, tell us and we will confirm when it starts resolving correctly.
Kind regards, [Agent name]
Ticket 7: Email Messages Are Rejected Because of Authentication or Reputation Issues
Customers report that mail bounces or lands in spam. The bounce message is the evidence. Codes mentioning SPF, DKIM or DMARC point to missing or wrong DNS records. Messages mentioning a blocklist point to reputation, which may be the sending address or the sending server.
Check records first and server reputation second. If one of our sending addresses is listed, that is ours to fix and the ticket should escalate. If the records are missing or contradict each other, that is a configuration matter. Our MailChannels corporate email option exists partly because deliverability needs this kind of care, though correct DNS records are still required on the customer’s domain.
READY REPLY
Hi [Name],
Thanks for sending the bounce message. We checked the email setup for [domain]. The rejection from [receiving provider] reads [short bounce text], which means [plain explanation].
Our check found that [SPF, DKIM or DMARC finding]. We also checked the sending server and it is not currently listed on the major blocklists. [If listed: it is listed on X and we are working on removal.]
Please add or correct the following DNS record: [record details]. Allow some time for it to take effect, then send a test message and tell us the result. If it still bounces, send the new bounce text and we will look again.
Kind regards, [Agent name]
Ticket 8: An Email Client Has Incorrect SMTP Settings
The mailbox works in webmail but not in a phone or desktop app. That already tells you the server is accepting mail. Common causes are the wrong outgoing server name, the wrong port, the wrong encryption type or a username entered without the full address.
Ask which application and device the customer uses, and what error appears. Then give the exact settings in one block so there is nothing to interpret.
READY REPLY
Hi [Name],
Good news: your mailbox [address] is working. We confirmed that you can log in through webmail, so the problem is in the settings of [email app] on [device].
Please use these settings. Username: your full email address. Incoming server: [server]. Incoming port: [port] with [encryption]. Outgoing server: [server]. Outgoing port: [port] with [encryption]. Outgoing authentication: on, using the same username and password.
If the app still shows an error, send us the exact wording or a screenshot and we will take it from there.
Kind regards, [Agent name]
Ticket 9: A Domain or DNS Change Has Not Fully Propagated
The customer changed a record an hour ago and still sees the old result. DNS answers get cached by resolvers around the world for as long as the record’s time to live allows. Some visitors see the new address while others still see the old one, which looks like a fault but is normal behavior.
Check the answer from several public resolvers and from the authoritative nameserver. If the authoritative server returns the new value, the change is correct and only caches remain. Changes usually settle within a few hours, though a long time to live can stretch that to a day or two. Do not promise an exact time.
READY REPLY
Hi [Name],
Thanks for your message. We checked the DNS for [domain] and the authoritative nameserver is already returning the new value, [new value]. Some resolvers are still holding the old answer, which is normal after a change.
This usually clears within a few hours, though it can take up to [TTL based time] depending on the record settings. In the meantime you can restart your device or flush your local DNS cache, and testing from a mobile network often shows the newer result sooner.
Please avoid changing the record again, since that restarts the wait. If the old result is still showing after [time], reply and we will look again.
Kind regards, [Agent name]
Ticket 10: An SSL Warning Comes From a Domain or Application Configuration Error
Browsers show a security warning, and the customer assumes the certificate is broken. Check what the warning actually says. A name mismatch means the certificate does not cover the address visited, such as the version with or without www. An expired certificate points to renewal. A mixed content notice means the page loads some images or scripts over plain HTTP, and that is a site setting, not a certificate fault.
Check the certificate details on the server, the address in the browser and the site URL setting. If you resell certificates through something like our SSL reseller program, also check that the certificate was issued for every name the customer uses.
READY REPLY
Hi [Name],
Thanks for reporting the security warning on [domain]. We checked the certificate on the server. It is valid until [date] and was issued for [names covered].
The warning you see says [warning text]. That means [plain explanation, such as: some images on the page load over HTTP, or the address you visited is not covered by the certificate].
To fix this, please [specific step, such as: update the site address to start with https, or visit the version of the address the certificate covers]. If the warning continues afterward, send us a screenshot with the full address showing and we will investigate further.
Kind regards, [Agent name]
What Should Hosting Support Replies Include to Help Customers Resolve These Issues?
Acknowledge the report, say what you checked, ask for the exact error and steps, give one clear next action and say when you will escalate. That structure works for every ticket above, and it keeps a reply useful even when the answer is “this is not the server.”
Acknowledging the Report and Explaining the Initial Findings
Open by showing you read the ticket. Name the domain, the symptom and when it started, in the customer’s own words where possible. Then give your first finding in a sentence or two.
Skip filler about how sorry you are to hear it. A customer with a broken site wants evidence that someone is looking at it. A specific first line does more for trust than three sentences of sympathy.
Stating What Has Been Checked on the Hosting Side
Say plainly what you tested. Server status, service health, account resources, logs and reproduction results are all fair game. Include the time of the check, because a result from last night means little this morning.
This single habit prevents most back and forth. A customer who sees that the server, the logs and the DNS were all checked will not reply with “did you even look?” It also protects your team when a ticket is reviewed later.
Requesting the Exact Error Message and Reproduction Steps
Ask for the precise error text, a screenshot with the full address bar visible and the steps that lead to the problem. Add the device and browser or app involved. Vague reports waste a round trip.
Keep the request short and specific. “Please send the exact message and what you clicked just before it appeared” beats a paragraph of questions. Ask for no more than three things at once, since customers answer short lists and skip long ones.
Providing a Clear Next Action Without Making Unsupported Claims
Every reply needs one next step the customer can take now. Make it concrete, such as renaming a folder or adding a record, and say what result to expect. Avoid promises you cannot keep, like a fixed time for DNS to settle or a guarantee that a plugin is the only cause.
Use careful wording where the evidence is incomplete. “The logs point to” is honest. “This is definitely” is a risk, because the next log line may prove you wrong.
Escalating the Issue When Evidence Points to the Hosting Environment
Sometimes the evidence says the fault is ours. A failing service, a listed sending address or a resource problem on the server belongs with a senior technician, and the reply should say so directly. Tell the customer that you are escalating, what you found and when they will next hear from you.
For providers who run a reseller business, this is where a clear escalation route to your upstream host matters most. If you run reseller hosting or a master reseller hosting setup, agree in advance what you handle first and what goes to your provider, so customers are never bounced between teams.
How Can You Adapt Ready Made Replies Without Frustrating Customers?
Replace every placeholder with real details from the ticket, cut jargon and give one specific step. A template is a starting frame and not the reply itself. If a customer can tell they received a copied message, the template has failed.
Personalizing the Reply With the Customer’s Domain and Error Details
Insert the actual domain, the actual error text and the actual time. Quote the log line when it helps. A reply that mentions the right plugin name or the right record value proves the checks happened.
Do a quick scan before sending. A leftover placeholder in square brackets looks careless, and we have all sent one at least once. Make it part of the routine to search the draft for brackets.
Avoiding Blame and Overly Technical Language
Describe causes as situations and not as mistakes. “The plugin update conflicts with your theme” is fine. “You installed a bad plugin” is not. Customers who feel blamed stop cooperating.
Explain terms in half a sentence when you must use them. “The DNS record, which tells browsers where to find your site” costs ten words and saves a follow up ticket. Match the customer’s level, and if they use technical terms themselves, you can too.
Giving Customers a Specific Troubleshooting Step
Tell them exactly where to click or what to type, and what they should see afterward. One step at a time works better than a numbered list of eight, particularly for non technical customers. If the first step solves it, they never need the rest.
Add a fallback line. “If that does not work, reply with a screenshot and we will take another look” tells the customer the conversation is still open and keeps the ticket from going quiet.
Explaining What the Hosting Team Can Investigate Further
Even when the cause is outside the server, say what you can still do. You might review logs again after a change, check mail delivery on the server or confirm a DNS record from our side. That shows the customer you are not closing the door.
Be honest about limits as well. We cannot edit a customer’s registrar settings, rewrite plugin code or fix an outside service. Say so clearly and kindly, then point to who can.
Maintaining a Consistent Tone Across the Support Team
Customers should get the same quality of reply no matter which agent answers. Keep a shared library of templates with one agreed tone, written in plain language and reviewed by the team lead. Update it whenever a reply gets a confused response.
Consistency does not mean identical text. Agents should be free to adjust wording to fit the person. What stays the same is the structure: acknowledge, show evidence, give a step, offer a next move.
How Can Hosting Providers Reduce Repeated Tickets About Issues Outside Hosting?
Publish troubleshooting guides, improve onboarding, tag tickets so patterns show up, define your support scope in writing and review repeat tickets on a schedule. Prevention takes some effort up front and pays back every week afterward.
Creating a Customer Facing Troubleshooting Knowledge Base
Write a short article for each ticket type in this guide. Use the customer’s own phrasing for the title, such as “My site shows a white screen,” because that is what they will search for. Keep each article to a symptom, a quick test and a fix.
Link the articles inside your replies and from your support portal. A customer who solves the problem alone at 2 a.m. is a ticket you never had to answer. Be realistic though: some customers will always prefer to ask a person, and that is fine.
Improving Website Setup and Onboarding Documentation
Many tickets begin as setup mistakes in the first week. Provide a welcome guide covering pointing a domain to the account, creating email accounts, installing an SSL certificate and taking a first backup. Include the nameservers and mail server settings in one place.
For resellers, put the same material in front of your own clients. Our Compare Reseller Features page shows what comes with reseller plans, and that list is a good starting point for deciding which topics your onboarding guide needs to cover.
Using Ticket Tags to Identify Recurring Issues
Tag every ticket with its cause category as you close it, such as plugin conflict, DNS, email authentication or caching. After a month, the tag counts tell you where your time actually goes. Guessing is usually wrong.
A helpdesk built into your billing system makes this easier. WHMCS includes a support ticket system alongside billing and client management, so tags and customer history live in the same place.
Defining Support Scope and Escalation Rules
Write down what your support covers and what it does not. Cover areas like server and account issues, basic guidance on common applications and the point at which a customer should hire a developer. Publish that in plain words where customers can find it.
Pair it with internal escalation rules. Decide who handles server faults, who handles mail reputation and how fast each should respond. A clear scope removes arguments, and it keeps agents from drifting into free development work.
Reviewing Repeat Tickets to Find Opportunities for Prevention
Once a month, read the most common ticket types and ask what would have stopped them. A recurring caching complaint might need a clearer guide. A recurring email rejection might need a default record added at account creation.
Not every repeat ticket can be prevented, and trying to remove them all is a waste of effort. Aim for the top three causes and measure whether they shrink next month.
A good support reply shows its evidence, keeps the customer calm and gives them one clear thing to do. Adapt these ten replies to your own voice and test them on real tickets this week. If you are building a hosting business and want support backed by a team that has handled these tickets for two decades, see how our end user support works for resellers and their customers.
