Frequently Asked Questions

The NearlyFreeSpeech.NET FAQ (*)

Member Support (*)

What is the status of my support issue?

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:

Available
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."
Received
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!"
In Queue
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.
Pending Auto-Close
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.
No Subscription
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.
In Progress
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.
Awaiting Response
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.
Pending Verify
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.
Waiting
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
Blocked issues are awaiting response or information from a third party (i.e. not you and not us).
Sleeping
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.
Completed
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.
Killed
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.

How can I get specific software installed for my site?

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. We're responsible for: The operating system, system tools & utilities, programming languages, and their core libraries.
  2. We're responsible for: third-party libraries and modules that are particularly common, popular, or that require regular updates.
  3. You're responsible for: third-party libraries and modules we don't provide that your site needs to work properly.
  4. 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:

What is a system problem?

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.

Do I really have to buy a subscription membership just to get a simple question answered?

No.

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.

Why was my system problem report closed as "works as configured?"

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.)

What are the options available for member support?

We provide a number of support options designed to meet various needs.

Self-Help Options

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.

What are the various responses to a system problem report?

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.

Problem Resolved
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.
Insufficient Information
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.
Problem Identified
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.)
Duplicate
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.

How can I give you private feedback about your service?

We love feedback! You're welcome to send email to feedback@nearlyfreespeech.net 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.

Why was my system problem report closed as "not a system problem?"

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.

How do system problem reports work?

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:

  1. Clearly describe the problem, including all relevant information.
  2. Demonstrate that the definition of a system problem has been met, or, if you can't be sure, at least show that you know the definition and reasonably believe it fits.

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.

Can you help me restore something that has been deleted?

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:

  1. Open a recovery assistance request describing what you would like to restore and the time period from which you would like it restored.
  2. We will invest the time to determine what can likely be recovered and how much it will cost to do so. (There is a fee for this unless you have a subscription membership.)
  3. Based on the cost and expected results, you can decide whether or not to proceed with the restore and make sure you have the necessary funds available in your account.
  4. If you decide to proceed, we will debit your account for the cost and perform the restore.

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.

How do I "cash out" unused support points?

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.

Why don't you answer @nfsn tweets?

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.

Why don't you provide free support?

Short version: Because support costs money to provide, and our service is based on a "pay for what you use" principle.

Long version:

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:

  1. 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.)
  2. 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.)
  3. Hide the cost with higher prices for other services.
  4. Charge a flat monthly fee that is completely independent of usage.
  5. 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.)

Why don't you provide more detail in response to system problem reports?

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:

  1. They are free.
  2. They go to the front of the line.
  3. They are handled outside our standard support hours.

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.

What is an assistance request?

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.

How do I buy support points?

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.

What if I can't figure out which support option to use?

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.

Why does your support cost so much?

It doesn't.

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.

Why shouldn't I wait until I need support to set up a subscription membership?

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.

What are support hours and expected response times?

Our standard support hours are:

Monday - Friday
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.