Home › Support
Support
One route, no tiers, and no promised response time until we have one we would be willing to be held to.
How it works
You describe the problem and a person who can change the server reads it. There is no first line, no escalation path and no ticket that gets closed because it went quiet.
That is a consequence of being small rather than a service innovation, and it has an obvious limit: a small operation is not staffed around the clock. We would rather say that than imply otherwise.
No response time is published on this page. Hosting companies publish those routinely and most of them are marketing. When we have a commitment we are confident in, it will appear here as a specific number. Until then, ask what currently happens and you will get a straight answer.
What to include
If something is broken, three things get it looked at fastest:
- The domain
- What you were expecting to see and what you saw instead
- When it started, and whether anything changed just before
A screenshot of an error is worth more than a description of it, because the exact wording usually identifies the cause.
What we can fix
Anything on the server: configuration, certificates, redirects, PHP settings, permissions, the error that appeared after a change. If the site is one we built, the site itself as well.
Problems we can diagnose but not fix are worth naming too, because knowing where the fault is saves you time: a domain pointing at the wrong place when the registrar is elsewhere, email hosted by another provider, or something inside a third-party application we did not build.
What we will tell you is not worth fixing
Some things that look like faults are not, and some that are faults are not worth the money.
A search ranking that has moved is not a server problem, and nobody should charge you to investigate it as one. A page speed score that is not perfect is usually not worth chasing past the point where the page already loads quickly. And a warning in a diagnostic tool is not automatically a problem: on a newly moved domain, the most common cause of structured data warnings is the for-sale page the domain used to have, which is nothing to do with the site now on it.
Planned work
Where we need to make a change that could interrupt a site, we say so beforehand. Where something needs doing urgently for security, we do it and tell you afterwards, which is the right order for that particular trade-off.
Something broken?
Put the domain at the top of the message and it gets looked at before anything else.