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:
This means an issue has been created through our secure support system, but has not yet been picked up by or assigned to a specific individual yet. "Please hold for the next available representative."
Since we can't provide membership-private information in response to email requests, issues that are created from emails sent to support@NearlyFreeSpeech.NET are marked as "Received" instead of "Available." Issues like this will usually have to be resubmitted or confirmed by logging in to your membership (provided you are eligible for email support), but we'll read them first to make sure they don't say, "Help, I can't log in to my membership!"
Once a specific person has reviewed and claimed your issue, it moves to the "In Queue" status. Issues in this status are typically worked on in the order in which they are received or updated, subject to the issue's requested priority level and our best judgment.
Once we have responded to an issue, we will usually consider it resolved unless you reply back within 24 hours with more information. During those 24 hours, the issue will be flagged as "Pending Auto-Close" in our system.
This an issue that would qualify for individual support under a subscription membership, but the person who submitted it has a baseline membership that does not include individual support, so we cannot proceed with it. If you obtain a subscription within 24 hours, the issue will be automatically reactivated. Otherwise, it will time out and our system will close it.
It's relatively rare to see an issue in this state, because most issues are resolved quickly and move straight from "In Queue" to "Pending Auto-Close." However, if an issue requires an unusually large amount of work to complete, we try to move it into the "In Progress" status while we work on it to let you know that. This most frequently happens with things like installation of software into our CGI environment.
Sometimes we can't allow an issue to be closed until we hear back from you. Usually that happens when we open the issue instead of you. In such cases, the issue moves to "Awaiting Response" until we hear from you.
After we've established that a "Received" issue doesn't involve logging in, we'll send you a message telling you to log in and confirm it. Once that's done, your issue moves to this state. If you don't confirm it within 24 hours, it'll close and you'll have to start over.
This issue was received or updated outside our normal hours. Once our standard support hours arrive, it will automatically change to some other more appropriate status. (During the day, our system only checks its watch once per minute, so a new or updated issue might linger as "waiting" for up to a minute before jumping over to a more active status.)
Blocked issues are awaiting response or information from a third party (i.e. not you and not us).
Sometimes we need to defer an issue for a specific amount of time. For example, we may say "we'll check this tomorrow afternoon to make sure it is still working." In such cases, the issue is marked as "Sleeping" until the appointed time arrives. Sleeping issues provide their own built-in alarm clocks.
When happy issues reach the end of their life with us, they go away to live at the "Completed" farm where they are free to run and frolic all day long.
People (usually non-members) occasionally send email to support or abuse like "Please take down the so-and-so site! It offends me." The resulting issues do not get to go live on the farm.
With respect to the software we provide, our goals are:
To give you the strongest and most stable possible foundation upon which to build your site.
To minimize the amount of work you have to do to keep your site's infrastructure up-to-date and secure.
To do both of those things while still giving you as much flexibility as possible to build what you want.
To meet those goals, we divide software into four broad categories, two that we're responsible for and two that you're responsible for:
We're responsible for: The operating system, system tools & utilities, programming languages, and their core libraries.
We're responsible for: third-party libraries and modules that are particularly common, popular, or that require regular updates.
You're responsible for: third-party libraries and modules we don't provide that your site needs to work properly.
You're responsible for: your site's application code and data.
#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:
client applications (like email or IRC clients)
applications (like content management systems) that require extensive per-site customization
software that requires a commercial license to use
customized packages or nonstandard configurations
packages with specialized installation or configuration requirements
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:
A malfunction: Something is broken.
In our systems or network: What's broken is something that we maintain as part of the services we provide.
Negatively affecting: It actually has to be causing a problem.
Previously working: It used to work, and then it broke. If XYZ has never worked, it is not a system problem that it is currently (still) not working.
Production services: Issues with test sites and beta services can't be treated as system problems.
That requires the manual intervention of our system administrators to resolve: We have to use system-level access that you don't have to fix it. Even if you had perfect knowledge about what the problem is and how to handle it, you still wouldn't be able to fix it yourself.
Typical system problems include:
downed network links
routing problems inside our network
DDOS attacks on sites other than your own that are negatively affecting you
extreme misbehavior by sites other than your own causing "spillover" problems that affect you
A few examples of things that are not system problems include:
Not knowing how to do something.
Buggy or broken code on a site.
Any problem inside a running member MySQL process.
Performance problems arising from your own inefficient or excessive resource utilization.
Attacks of any sort specifically targeting your site.
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:
A web site is not responding or produces a system error message that does not include a link to a FAQ entry explaining the error and what to do about it.
A MySQL process is unreachable or drops connections when accessed with correct login/password credentials.
Our DNS servers return an error or no response at all for records that are correct in the member interface.
Our member interface returns an error message while trying to perform a valid function.
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:
You may have configured something and then forgotten about it.
Something may have been configured unintentionally. (E.g. by accidentally clicking a button in the member interface or misreading a form field.)
A configuration may not have the effect you expected it to.
It may be a default setting that isn't actually a fit for your situation.
Here are some common examples of "Works as Configured" issues:
"My site returns 'connection refused.'" (The site is set to use a custom web server,
but no custom web server is set up.)
"It says my FTP login is incorrect." (The site or membership is set not to allow FTP.)
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.
This FAQ. It contains a lot of detailed information about how our service works and how to do various things. This is a one-way communication channel where we provide you with information we think it is important for you to know.
Our Member Wiki which contains tons of useful information contributed by our members about what does and doesn't work on our system. This is an "all ways" communication channel, since any member can add or edit information.
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.
If there is a system problem affecting your service, you can open a free System Problem report. This isn't really a support option, it's a one-way communication mechanism you can use to tell us about something you believe is a problem.
System problem reports are technology-limited to various predefined responses, so it's not a way we can provide you with information.
System problem reports have their own FAQ entry.
For certain pre-determined tasks that need us to do something on your behalf, we have free assistance requests. The opportunity to open assistance requests is often context-specific, but there is an index of them on the Assistance Request page.
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.
We have resolved the reported system problem. Yay!
Not a System Problem
We investigated the report and found that it was not a system problem. This response has its own FAQ entry.
Works as Configured
We investigated the report and found that at some point you set up or requested the specific behavior you have now reported as a system problem. This response also has its own FAQ entry.
No Problem Found
We investigated the report and we were unable to reproduce the problem described. There are two basic ways this can happen:
The problem went away by itself before we got to it. Our systems are designed to auto-recover many types of failures. A DDOS attack affecting it may have stopped on its own. Many Internet problems are intermittent and short lived.
Everything is working fine on our end and the problem is elsewhere, like a problem between your ISP and our network.
Beta Problem Exclusion
The problem you are reporting is related to your voluntary opt-in use of beta or experimental services. Problems arising from the beta/experimental nature of these services are specifically excluded from the definition of a system problem.
We need more information to investigate the report. This most often happens if someone says "my site is down" but has more than one site and doesn't specify which one it is, or something similar. You can reply back with additional information and we can give it another check. For some guidelines about providing more information, please see this FAQ entry.
We have confirmed a problem related to the report and resolution is in progress. (These are rarely sent; they are used only when resolution is expected to take a particularly long time so you'll know we're working on it.)
The reported problem is a duplicate of a previous report or a problem that is reported or documented elsewhere. To avoid duplication of effort, this report is being closed. If you didn't submit the report more than once, check main support tab or the offsite status page to see if more information is available.
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.
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:
I cannot log in to FTP/ssh. (Member is using the wrong login credentials or has a local firewall issue blocking access.)
I get permission denied when trying to upload. (Member is trying to upload to the wrong directory.)
My site is down but I can still see (other site). (Member's domain is expired or an Internet network between us and their ISP is having a problem.)
My email forwarding is silently dropping email. (Member's email is usually being forwarded properly and being dropped at the far end; we do not silently drop messages -- they either bounce, get quarantined, or get forwarded.)
My XYZ suddenly broke and it must be a system problem because I haven't touched it in ages. (XYZ depends on ABC which was discontinued by its developers years ago and we finally had to drop it after warning we would well in advance.)
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.
We love feedback! You're welcome to send email to firstname.lastname@example.org 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.
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:
Clearly describe the problem, including all relevant information.
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 to some people, we feel it is particularly ill-suited for working together with our members to find and solve problems.
So, if you send an @nfsn Tweet, keep in mind:
We don't have any PR people or a "social media team." There's no one here who's job it is to look at (or post on) Twitter, so we may not even see a tweet for several days.
Even if we see your Tweet, we're unlikely to have the information at hand needed to answer.
We probably won't know who you are anyway.
Even if you tell us who you are, we can't take someone's word for it over Twitter.
The answer almost never fits in the length of a tweet. (And most people can testify that trying to force things to fit can consume a ridiculous amount of time.)
Answering the few questions we could answer would just mislead people who haven't read this into asking questions that we can't answer and then frustrate them when we don't.
As with all forms of feedback, we value what you have to say, and a real person will (probably, eventually) read everything Tweeted to @nfsn. So feel free to use it to say what's on your mind, as long as you understand we won't answer.
Should you want a reply, we recommend using one of the member support options that allows us to provide one, or just post on our forum.
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:
The company can operate at a loss, backed by investors, trying to slurp up customers by giving away service, including support. (This approach still charges for support, it just charges the investors instead of you.)
The company can offer "free" services, including support, by inserting ads into your hosted content. (This approach still charges its customers for the cost of providing you support. Bad news, you're not the customer in this model, you're the product.)
Hide the cost with higher prices for other services.
Charge a flat monthly fee that is completely independent of usage.
Charge for support directly.
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.)
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:
a confirmation that the request has been completed, or
a response indicating that the request was unsuccessful.
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.
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.
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.
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.
1pm - 9pm US Eastern time (10am - 6pm US Pacific time)
Saturday, Sunday & Holidays
3pm - 7pm US Eastern time (12pm - 4pm US Pacific time)
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.