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. (You can also retrieve the text of an issue in this status using the View Support History action from the Support tab, for example to repost it to our forum.)
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 a farm upstate.
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 while 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 it becomes that we should provide it. If a module requires customization, imposes restrictions, or often has backward compatibility issues, 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.
Node.js
We provide the node binary and the npm and yarn package managers. You can use these to install needed dependencies to the current directory. (E.g., npm -g will not work.)
Perl
You can use local::lib to set up a per-site repository that will work with CPAN to allow you to obtain and use exactly the modules you want. We do 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.
PHP
We provide PHP binaries and core extensions (both built-in and from PECL). We add extensions only if they are of great general interest. We recommend the use of Composer or a similar tool to set up and manage your application's PHP environment. This will ensure 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. You may also build and use extensions we do not provide.
Python
We strongly recommend using virtualenv or a similar tool to set up and manage your application's python environment. (Note that Conda does not work well on FreeBSD.) However, 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 a virtual environment with 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 or are especially difficult to build properly. (Numpy, we're looking at you.)
Ruby
We provide Ruby binaries and the gem package manager. We tend not to provide many centrally-installed gems. We recommend setting the $GEM_HOME environment to a path of your own (e.g., /home/protected/gems) and using gem or bundler or a similar tool to set up exactly (and only) the modules you need. This will ensure 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.
Others...
For other languages or general-purpose utilities, we rely on the FreeBSD ports collection, which contains 27,000+ software packages. If a package is of sufficient general interest (and not in one of the prohibited categories below), we are generally able to provide it.
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.
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:
games
client applications (like email or IRC clients)
GUI applications
applications (like content management systems) that require extensive per-site customization
software that requires a commercial license to use
Apache modules
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:
crashed servers
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:
Expired domains.
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 SSH login is incorrect." (The site or membership is set not to allow SSH.)
If the issue is related to a web site, the "Troubleshoot Site" action (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
Self-help options are always free. They include:
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 is free and available to all members. 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 support 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.
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.
Recovering deleted files from a site
If you've accidentally deleted a file or files on your website, or you want to roll back to a recent backup, you may be able to fix that yourself. On the ssh server, the /home/.zfs/snapshot directory allows you to access historical snapshots of your site. Snapshot names are 12-digit numbers based on the date and time the snapshot was created, in the form YYYYMMDDHHMM. For example, if a snapshot is named 202401021200, then it was created on 2024-01-02 at 12:00 UTC. A site may have up to 60 snapshots covering the past 30 days, depending on how large the site currently is, how fast the site's content changes, and how long ago it was created.
You can copy individual files out to the live site:
The --dry-run flag will cause rsync to tell you what it would do instead of doing anything, so you can make sure the behavior is what you expect. Once you're sure you're putting the right files in the fight place, run rsync without --dry-run and it will perform the operation for real.
The rsync command also supports --delete and --force flags (among many others), which may be useful to make sure there aren't other stray files laying around. But these flags can also be very dangerous; if the command isn't exactly right, they may delete something other than what you intended.
Recovering sites or MySQL processes that have been completely deleted
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 us to produce this estimate unless you have a subscription membership.
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.
If you decide to proceed, we will debit your account for the cost and perform the restore.
Rolling back a MariaDB 10.x process to an earlier state
As with deleted sites and MySQL processes, use the Attempt to recover deleted content assistance request. The process is very similar, although the costs are much, much higher. Further details are under the appropriate heading on that page.
Other deleted content
Registered domains can be recovered for a little while after they expire.
Removed DNS or email forwarding settings cannot be recovered.
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.
We take all system problem reports seriously. 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 investigate 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. However, the generic "not a system problem" response doesn't provide that information. (To understand why we do this, please see this FAQ entry.)
We find that members sometimes submit invalid system problem reports if they have a 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 report 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.
We also find that members are sometimes confused about which support mechanism is right for their situation. System problem reports are not a way to get support, free or otherwise. 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. 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 first.
Another difficulty we encounter is an inappropriate definition of "system problem." Anything that doesn't work as expected, this theory goes, qualifies as 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 ensure you're using our definition when reporting a system problem since that's what we will use when responding to the report.
Here are a few examples of common issues that may appear to be system problems but aren't:
I cannot log in to 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 forwarded properly but dropped at the far end; we do not silently drop messages -- they 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 someone, and system problem reports aren't a way to do that.
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.
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.
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.
Our official Twitter handle is @nfsn. However, as of 2023, it is functionally inactive.
We had already decided Twitter was a raging dumpster fire when its new ownership started trying to drown it with gasoline. Twitter's apparent purpose is to manufacture rage and induce conflict. We don't think those are useful properties for a communication channel. Nor are they well-suited to working together to find and solve problems. As a result, Twitter is not a method we use to interact with our members.
We always value what our members have to say. If you want to share your thoughts with us or need help with something, please use our forums or check your options on the Support tab of our member interface.
(Yes, we know about "the artist formerly known as Twitter." No, we're not calling it 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:
Clearly describe the problem, including all relevant information.
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.
Assistance requests allow us to 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. In general, they receive one of three responses:
a confirmation that the request has been completed,
a response indicating that the request was unsuccessful,
a response indicating that the request is out of scope.
Success or failure notifications may be accompanied by a brief error or diagnostic message based on the type of request.
An "out of scope" response means that whatever you asked or requested was not something that can be processed through the automated assistance request system.
If you receive an "out of scope" response, no further reply you make to that issue will be seen or acted on by anyone unless you have an active subscription membership or obtain one within 24 hours.
In general, if the responses "completed" or "unsuccessful" do not fully address your concern, an assistance request is probably not the correct support mechanism.
The other options for member support vary depending on what type of membership you have; please see this related FAQ entry for details.
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, tech support is a very difficult job that requires extensive technical and people skills, almost constant training, and a lot of dedication.
The money to pay people to do that hard job has to come from somewhere. So all web hosting companies charge for support, and there are five ways to do it:
Operate at a loss, backed by investors, trying to slurp up customers by giving away service, including support.
Offer "free" services, including support, by inserting ads into your hosted content.
Hide the cost of "free" support by charging higher prices for other services and including support, like a "free" prize in a cereal box.
Hide the cost of "free" support in a flat monthly fee that is completely independent of usage.
Openly and honestly charge for the service of support.
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. It's still charging for support, it's just charging the investors instead of you.
Option 2 can work if everyone involved has low enough expectations. But they are charging their customers for the cost of providing you support. You're just not their customer.
Most companies choose options 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.
As a "pay for what you use" service, we use option 5. If you're willing to commit to not asking for 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 never or only rarely use support can save substantially over the long term.
Second, people who want support beyond what the forum offers may pay somewhat more, or at least somewhat more visibly, for it here than they would somewhere else, 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 it. It's hardly expensive as monthly web hosting fees go and we do our best to make the support we provide worth the price.
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. (An understandable situation, but not anything to do with us.) At midnight, Person A submits a paid support issue and Person B submits a system problem report. Without limits on system problem reports, they get the same response but Person B gets it hours sooner and for free. That creates a perverse incentive to misuse the system.
So we built a third system that charged for system problem reports. That was also a terrible idea. (It burned down, fell over, then sank into the swamp.) If you find a system problem, we don't care how much money you do or don't have, we want to hear about it.
As a result of all that, we allow free system problem reports but limit the responses. That has worked out very well for both us and our members. (But the fourth one stayed up!) System problems get fixed promptly, and there is no benefit obtained by reporting things that are not system problems.
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 small. (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)
During these hours, we attempt to maintain an average response time of under two hours for all assistance requests and inquiries from subscription members. Complicated requests and asset transfers between memberships can sometimes take longer, and cancellations are typically only processed once a day.
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.
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.
