Frequently Asked Questions
The status of your support issue is indicated on the "Current Status" line in the issue summary on the support tab. Here's an explanation of the terms you might see there:
With respect to the software we provide, our goals are:
To meet those goals, we divide software into four broad categories, two that we're responsible for and two that you're responsible for:
#1 and #4 are clear enough, but the demarcation line between #2 and #3 is always a tricky balancing act. The lower-level a module, or the more security implications it has, the more likely that we should provide it. The more customization a module needs, the more restrictions using it imposes, or the more often it has backwards compatibility issues, the more likely that you should provide it.
This entry discusses how you can install third-party libraries modules yourself for the most common languages, and how to request that we install things when appropriate.
For PHP, we recommend the use of Composer or a similar tool to set up and manage your application's PHP environment. This will make sure that the modules (and versions of those modules) that your application expects are present and that they don't change out from under you as we continuously update our system. Consequently, we provide only PHP binaries, core extensions (both builtin and from PECL), and a library of commonly-used PEAR modules, and we can only install additional modules if they are of great general interest.
For Python, we strongly recommend the use of virtualenv to set up and manage your application's python environment. Unlike other languages, Python's performance degrades as more modules are added to its central library; you will usually get better performance and a more stable site if you use virtualenv feature to set up exactly (and only) the modules you need, rather than diving into the deep pool of modules provided by our system. Consequently, we can centrally install PIP modules if (and only if) they are of great general interest.
For Ruby, we recommend setting the $GEM_HOME environment to a path of your own (we recommend /home/protected/gems or similar) and using gem or bundler or a similar tool to set up exactly (and only) the modules you need. This will make sure that the modules (and versions of those modules) that your application expects are present and that they don't change out from under you as we continuously update our system. Consequently, we can centrally install Gems if (and only if) they are of great general interest.
For perl, you can use local::lib to set up a per-site perl module repository that will work with CPAN to allow you to obtain and use exactly the modules you want. We can also centrally install modules from the CPAN archive with appropriate justification. In this case, there is an additional requirement that the module's built-in tests pass in our environment.
If you have questions about how to perform per-site module installation for one of these languages, please review the support tab for your support options.
For other general purpose utilities not specific to one of the above languages, we rely on the FreeBSD ports collection, which contains 27,000+ software packages. If a utility is of sufficient general interest (and not in one of the prohibited categories below), we are generally able to provide it.
To request that we centrally install a new software package, please submit an Assistance Request. (Make sure to follow the instructions on that page.)
When we install software, we require that the requested software package have some applicability to web hosting, and that central installation of the software will not interfere with others' use of the service. For example, we cannot install the following categories of software:
The definition of a system problem:
A system problem is a malfunction in our systems or network negatively affecting previously-working production services that requires the manual intervention of our system administrators to resolve.
That is very dense, and each part has a specific meaning. Here's how it breaks down:
Typical system problems include:
A few examples of things that are not system problems include:
In most cases, you won't know what the specific system problem is. You have to detect them by the effects they have on your service. Some example effects of possible system problems would be:
However, situations do require interpretation. Sometimes the same effects can occur from both a system problem and something that is not a system problem. For example, if your website's domain name does not resolve because our DNS servers all crashed, that would be a system problem. If your website's domain name does not resolve because it is expired, that is not a system problem.
Our recommendations for who should obtain subscription memberships are outlined on our public site but in brief, unless either the services you obtain from us are mission-critical and need the fastest possible response regardless of circumstance or you plan to contact support on a regular basis (more than twice a year), we recommend the baseline membership.
If you do not have a subscription membership, but you do have a question, the best option is usually our community support forum.
We'll usually answer the same question for free in the forums that are covered by a subscription membership, because when we answer a question in the forums, everyone can see and benefit from the answer, not just the asker. (To get the best results from our forum, make sure you're helping the system work by demonstrating in your forum post that you've already searched the forum for people who have asked the same question in the past.)
We provide the option of a subscription membership to reflect the fact that the time of one or more professionals is being spent exclusively and privately on your issue.
So, in most cases, if you're paying for a subscription membership that you use to ask simple questions, you're not paying to have the question answered, you're paying to make sure a skilled professional is available to answer your question, and to have the answer provided privately.
Naturally there are exceptions, particularly if you need us to do something, rather than answer something. Once you get outside the realm of answering a question into an area where we're expending professional time investigating or explaining something on your behalf, the subscription membership is the most appropriate way for us to recover the associated costs.
This indicates that the behavior you reported as a system problem is actually the correct, direct result of how you have things set up. That's actually good news, because it means that it is under your control and you can resolve it on your own.
However, this response often confuses people, because if someone knows that they set something up a certain way, they usually don't report it as a system problem. So receiving this response typically indicates that one of the following has happened:
Here are some common examples of "Works as Configured" issues:
If the issue is related to a web site, our Site Troubleshooting Wizard (available from the Actions box on the Site Information panel for the site) can point out a lot of configuration issues that cause unwanted behavior.
It's often also helpful to go through our member interface and review anything in yellow, orange, or red text, or anything that says "Deprecated," "End-of-Life," "Obsolete," "Dangerous" or similar.
If you're unable to find the requisite setting to control the undesirable behavior, you may wish to post about your issue in our forum or, if you are a subscription member, open an individual support issue. (Although if you are a subscription member, "works as configured" responses are auto-converted to individual support requests.)
We provide a number of support options designed to meet various needs.
Self-help options are always free.
Community Support Options
Like self-support, our community support forum are free and available to all members regardless of what type of membership they have. They provide a venue for both members and staff to gather and exchange information about what's going on and how to do stuff. Like the wiki, this is an "all ways" communications channel where everyone can participate. In addition to our staff, lots of awesome volunteers hang out here, so this is a great way to get a fast answer to a simple question. (And often complex ones as well.)
Special-Purpose Professional Support
Like self-help options, our special-purpose support options are free. Unlike self-help, the scope of the special-purpose professional options is very limited.
General-Purpose Professional Support
If you would like to ask questions or get personal support from our staff in private, we provide that service through an optional, extra-cost subscription membership. If you have one, you can open a secure issue. If your question is within the scope of our support, we'll do our best to help out. Keep in mind that our service is do-it-yourself in nature, and a few dollars a month doesn't change that; this feature is used to request information from us to help you do something, it is not used to get us to do things for you. "Can you help me figure out why my site is slow?" is something we may be able to help with. "Please fix my site's code so it isn't slow" is not. Support provided through our subscription membership is also "best effort." We'll do the best we can to help out, and we're pretty good, but we're neither omniscient nor omnipotent, so we can't guarantee any particular outcome or result.
Because the system problem report feature is intended only to provide a no-cost mechanism to allow our members to let us know about malfunctions affecting their service, not as a general-purpose support mechanism, the responses we can generate are extremely limited. After we close your system problem report, you will receive an autoresponse based on our findings.
If you get a response that indicates that no problem was found or that the issue is not a system problem, then you may need more information to help understand what's going on. Although it may be tempting to reply to the autoresponse, don't do that! Messages to closed reports are not seen by human beings. We would recommend following up through one of our support options.
We love feedback! You're welcome to send email to email@example.com with any thoughts, comments, or minor bug reports about our service.
If you send a message to this address, we will definitely read it.
However, feedback email isn't a way to obtain member support; if it looks like your message would be better suited to one of our support methods, we'll try to convert or redirect it as appropriate so you can decide whether or how you want to follow up on it.
In short, this means that the issue you reported did not meet the definition of a system problem.
Most people submit system problem reports with a good faith belief that they're reporting a problem with our system. So it can be surprising and frustrating to see that we did not agree with their assessment, and we totally understand that.
It's very important to keep in mind that we take all system problem reports seriously, and when we close one as not a system problem, we're not blowing it off, we're not just doing it to be jerks, and we're not trying to pretend a problem doesn't exist. We investigated the issue enough to figure out what's going on, typically we can see exactly what the problem is, and it's not a system problem. But the generic "not a system problem" response doesn't indicate what the problem is or why it is not a system problem. (To understand why we do this, please see this FAQ entry.)
We find that sometimes system problem reports get submitted inappropriately because the member has a particular misconception about what such reports are for or how they work. One such misconception is that system problem is a synonym for important. This is not the case, and attempting to misreport something as a system problem because it's important to you is a recipe for frustration. The report will be closed, everyone involved will be irritated, and you will have to start over with lost time and an even higher frustration level.
If you want the fastest possible response about something important to you, then maintaining an active subscription membership is by far the best way to obtain that.
We also find that members are sometimes confused about which support mechanism is right for their situation or they prefer not to use our paid support. System problem reports are not a way to get support, free or otherwise. In general, if you're not sure which support mechanism is right for your needs or you prefer not to pay for support, try asking in our member forum.
Another difficulty we encounter is a redefinition of "system problem." Anything that doesn't work as expected, the theory goes, qualifies is a "system problem" because the system is not working as expected, and that's a problem. This is not the case. We have meticulously defined exactly what constitutes a system problem. Please make sure you're using our definition when reporting a system problem, since that's what we're going to use when responding to the report.
Here are a few examples of common issues that may appear to be system problems, but actually aren't:
Any one of those could be critically important to the person reporting them, but even if that's true, they still aren't system problems and can't be addressed through the system problem report facility.
If you do get a "not a system problem" response, your next course of action -- if you can't figure it out on your own -- should be to contact us through one of our member support options. This is true especially if you're sure we got it wrong, because at that point you need to talk to a person and system problem reports aren't a way to do that.
The most important thing to know about system problem reports is that if you're encountering a system problem and you think we don't already know about it, we want you to report it. Providing a reliable, high-quality service is really important to us, and system problem reports are an invaluable way for us to find out about subtler problems that can be hard for us to automatically detect.
The second most important thing to know about system problem reports is that if you submit one, you won't get an answer. System problem reports are essentially a one-way channel of communication. They are a free way for you to provide information about system problems to us, not vice versa. A decent rule of thumb is that if there's a question in your system problem report, or if you're expecting any response more thorough than "Thank you for your report," you're probably not reporting a system problem.
System problem reports are only one tool in the toolbox of options we provide for you to contact us. Like most tools, they are not appropriate for every situation. Also like most tools, in order to get good results, it's important for you to make sure that it's not only the right tool for the job, but also that you use it correctly. And like most tools, if you use it in the wrong situation, or use it improperly, the outcome will be bad, if not downright painful. Members occasionally torture themselves with a system problem report because it's the wrong tool for the job but they insist on using it anyway; we hate to see that.
Reporting a system problem is serious business, like pulling a fire alarm. We understand that mistakes happen, but our system does evaluate your past system problem reports when determining whether to allow you to report new system problems as well as what priority to give them. For this reason, we strongly encourage you to investigate the situation to the best of your ability before reporting a system problem. There are distinct "boy who cried wolf" consequences for people who repeatedly misuse the feature.
Once you submit a system problem report, we will typically receive and investigate it very quickly. Although our stated response is "as soon as possible," many system problem reports are closed within a few minutes of being created. But we do invest the time necessary to check out the report, so it may take longer.
After we've finished investigating the report and doing whatever we need to do, if anything, we'll close the report and you'll receive an auto-response. It will not satisfy your curiosity, and it will never answer any questions or provide guidance about actions you should take. To understand why this is, please see this FAQ entry.
That's pretty much that. Once we've closed the report, it's closed. You can't reply to it and we can't respond further or in more detail. If you want or need more information, you'll have to use one of our member support options to get it, such as paid support or the forum.
In all cases, we recommend following our troubleshooting tips before opening a system problem report, and writing a system problem report that shows you did so. The best system problem reports do these two things:
Making sure you cover both of those will help to ensure you get the quickest, most accurate, and most helpful resolution of your system problem report.
We strongly encourage members to make their own backups. However, sometimes that just doesn't work out, and people need to know what we can help them recover.
There are two types of content we can attempt to recover: Sites and MySQL databases. Each is described briefly below, followed by instructions for requesting that we attempt to restore something.
For sites, we keep incremental backups and we can generally help with most reasonable restore requests. We'll need to know exactly what files or directories to restore, and a point in time. Then we can try to restore the requested files from the last incremental backup from before that time. Our ability to do this is governed by available space, but it tends to be limited to restoring content removed in the past few months.
With MySQL, since we do not have administrative visibility into individual member processes, our backups are designed to recover the whole system, and they are designed to discover and back up changes as quickly as possible. Sometimes we can restore individual tables or databases that have been deleted, but the unit of backup is the whole process. We cannot roll back row-level MySQL changes. Also note that InnoDB tables typically cannot be recovered individually; they often require the whole process to be rolled back. If an entire MySQL process is deleted, we can usually recover it from backups within a few months, but we cannot offer any guarantees in that area.
In order to request that we restore a backup:
The cost to restore content will vary based on the amount of data to be recovered, the age of the backup restored, and the amount of sysadmin time required to do the restore. It tends to be in the range of $5 to $50 and is not covered by a subscription membership.
As long as you don't have any open issues that need points, you can select the "Cash Out Support Points" action from the Account Information panel for your account.
Support points are also automatically cashed out when a membership is closed.
We use Twitter mostly to broadcast brief updates to our members about downtime and announcements. In general, if there's an outage or a system problem, even a relatively small one, and we're able to post any information we can about it to Twitter, we will. However, it is not one of our methods of member support. While Twitter does have some value, we feel it is particularly ill-suited for working together with our members to find and solve problems.
So, if you send us an @nfsn Tweet, keep in mind:
As with all forms of feedback, we value what you have to say, and a real person will (eventually) read everything Tweeted to @nfsn. So feel free to use it to let us know what's on your mind, as long as you understand we won't be able to answer. Should you want a reply, we recommend using one of the member support options that allows us to provide one.
Short version: Because support costs money to provide, and our service is based on a "pay for what you use" principle.
The professionals who provide support do expect to be paid. And unless you're satisfied with the sort of people that mumble at you from prewritten scripts that may or may not be related to the question you asked, they expect to be paid pretty well. It's a very difficult job that requires extensive technical and people skills, almost constant training, and a lot of dedication.
That money has to come from somewhere. So all web hosting companies charge for support, and there are five ways to do it:
Few companies more than a year old use strategy number 1, because it's really expensive and the market is too competitive; they either change or fail. Number 2 can work if everyone involved has low enough expectations. Most companies choose a combination of 3 and 4. So they may claim it's free support, but it can actually be quite expensive, especially if you aren't using it. That's where we differ; we use option 5.
As a "pay for what you use" service, we believe that if you don't use support, you shouldn't have to pay for it. So our model recovers the costs of support only from the people who want it. This has two major effects.
First, people who use support may pay somewhat more for it here than they would somewhere else (although it's hardly expensive as monthly web hosting fees go) since the cost of providing it to them won't be subsidized by a bunch of other people who pay the same amount but never use support. We do our best to make the support we provide worth the cost.
Second, people who never or only rarely use support can save substantially over the long term.
Of course, free support options do exist, but they are based on the people involved volunteering their time. (Like our forums.) These options are generally pretty limited because those volunteers won't have access to information about your membership or services. But they can still often be very helpful. (Like our forums.)
Even though we investigate all system problem reports sufficiently to understand what the problem is, we provide only generic responses.
This raises an obvious question. If you're reporting a problem and we know what the problem is, whether it turns out to be a system problem or not, why don't we tell you what we found?
We've actually tried that in the past, and it was a disaster.
Like paid support, system problem reports are individual and private and handled by skilled professionals. However, system problem reports have several significant advantages over paid support:
Consider two people with the same problem: their site is suddenly offline and they don't know why. For both people, the cause is the same, their domain -- registered somewhere else -- is expired and they just didn't notice. (Which could happen to anyone.) At midnight, Person A submits a paid support issue and Person B submits a system problem report. Both people get the same response. But Person B gets it hours sooner and for free. Not only does that reward Person B for misusing the system, which is unfair to both us and Person A, but worse, there's no disincentive, so it also encourages Person B to do the exact same thing next time.
We can't charge for system problem reports, because system problems are largely budget-independent and if you find one, we don't care how much money you do or don't have, we want to hear about it.
As a result, we are forced to limit system problem reports in some way to prevent them from becoming a de facto 24x365 "free support" option that would have to be paid for through higher prices charged to everyone else (see option 2). Since we're not willing to do that, we have chosen to limit system problem reports by ensuring that they cannot be used to provide or obtain support.
Assistance requests provide a way to have us perform specific, predefined actions on your behalf that our member interface does not allow you to perform for yourself.
Processing of assistance requests is highly automated, and in general they receive one of two responses:
Either type may be accompanied by a brief error or info message based on the type of request. For example, a request to add TLS support to a site will return a list of names supported by the TLS files you provided if it succeeds, or a brief error message if the files couldn't be parsed into a key-chain-certificate set that matches the alias(es) on the site.
In general, if the responses "successful" or "unsuccessful" do not fully address your concern, an assistance request is probably not the correct support avenue.
Depending on your needs and what type of membership you have, you may be able to resubmit the request using our subscription-based support issue system, which does not impose such strict topical restrictions. If you prefer to minimize charges, one of our free self-support options, including our member forum, the FAQ, or the member wiki may meet your needs.
We no longer offer support points. If you happen to have a negative support point balance, the link to Purchase Support Points is found in the "Actions" box in the upper right corner of the Support panel. Otherwise, check out subscription membership instead.
If you've reviewed our member support options and you're not sure which one is right for your situation, we recommend posting the general, public-safe details of your situation in our Member Forums and asking for guidance. Someone will be glad to help you figure out what's the best way to go.
There are a couple of optical illusions that make it appear more expensive than it really is.
First, compared to the rest of the services we offer, the price of a support subscription is relatively high. If you want to make something look bigger, set it next to something smaller. (If we went in for manipulative marketing, we'd do the opposite: offer some hugely expensive incrementally better alternative that would make support subscriptions look like a bargain by comparison.)
Second, other providers tend to charge everybody for support whether they use it or not, either with a flat monthly fee or by hiding it in the cost of other services. This makes the cost of support appear lower than it is because if one person in five uses support, that person only has to pay 1/5th of the cost. But the other four are subsidizing him, getting nothing in return and there's nothing they can do about it. We refuse to do that. Our members will always have a choice.
Like the rest of our services, the price of a subscription membership is based on the cost of providing it; providing high-quality support is really expensive. And in addition to the cost of actually providing support, there are significant ongoing costs associated with making sure someone who knows what they're doing will be available when support is needed.
We've experimented with several models that offer less support at lower costs, with invariably poor results. Underfunded support leads to a soul-crushing contest to see who is more miserable: the members receiving inferior support, or the people who have to provide it. That's a game with no winners, and we won't play it. We are interested in providing support in one of two ways: really well, or not at all.
So, support costs (you) what it costs (us). We feel the subscription membership is a very good value that gives us what we need to be able to take good care of the people who select it. But what makes us really different is that we make it opt-in in an industry that usually doesn't even let you opt out.
There are three primary reasons.
First, we prioritize individual support requests based on the subscription member's past use of support. I.e. the less support you've used, and the longer you've been a subscriber, the higher you'll be in the queue and the faster the response time you will get. In contrast, newer subscribers and people who open many support requests may have to wait longer for a response.
Second, if you have been a subscription member for a long time but haven't needed much help, we will see that when you eventually do. Under some circumstances, we can use that to your advantage and spend extra time helping you troubleshoot an issue or digging deeper into our system to understand what's going on. When those opportunities arise, the metric we look at is how long you've been a subscriber.
Third is the philosophical reason. Most of the costs of providing you with support have been incurred before you ever seek support. Subscriptions help make sure that when you do seek support, there will be someone there to provide it, and that that person will be someone well-trained and capable of providing the best quality support possible. To put it another way, you probably don't want us to wait until you have a question to go out and recruit, hire, and train someone qualified to answer it.
We acknowledge that we can list as many reasons as we want, but asking you to subscribe to a feature the primary benefit of which is support before you need support is essentially asking for a leap of faith. When we look at a support inquiry and see that somebody made that leap and subscribed months ago, we do everything humanly possible to make them happy they did.
Our standard support hours are:
We do observe daylight saving time, although we think it's dumb and should be eliminated. If you're outside the US and want to see what time it is US Eastern time, Google will tell you.
During these times, we attempt to respond to all assistance requests and inquiries from subscription members with an average response time of under two hours. Complicated requests and asset transfers between memberships can sometimes take longer, and cancellations are typically only processed once a day.
Calling these our "standard" support hours is meant to indicate that we often respond to assistance requests and inquiries from subscription members outside these hours when we are able to do so; our goal is always to respond to member issues as quickly as possible.