Why hosting does not need your attention

The point of managed hosting is that the customer does not have to think about it. This is the marketing claim every hosting company makes. Few of them deliver it, and the reason is structural rather than operational. Delivering it requires accepting a relationship with the customer that most hosting companies have not been willing to accept.

This note describes what that relationship actually is, what it commits the operator to, and what the customer should understand about what they are buying when they buy hosting from a provider who takes the claim seriously.

What the customer is actually buying

Most of my customers are not technical. They run businesses. Their websites are operational tools for their businesses, not their primary expertise. They cannot independently evaluate whether their hosting infrastructure is well-configured, properly patched, monitored against the right threats, or backed up in a way that would actually allow recovery from a serious incident. They have neither the time nor the knowledge to assess these things, and they should not be expected to. Their job is to run their business; my job is to be the part of their business that knows how to run hosting.

This is a different relationship from the one most hosting providers describe. The standard hosting transaction is procurement: the customer specifies what they want, the provider supplies it, the customer is responsible for what they do with it. The provider operates the infrastructure; the customer is accountable for whether the infrastructure is adequate for their purposes. If something goes wrong, the provider absorbs the operational hit and the customer absorbs the business consequence.

What I actually offer is closer to professional services than to technology procurement. The customer hires me to apply my judgement to their hosting situation. They trust that I have made appropriate decisions about infrastructure, security, monitoring, and operational practice on their behalf. They are paying for the outcome (their site works, stays online, does not get compromised) and for the judgement that produces the outcome, not for the technical components themselves. If my judgement is wrong, their site is wrong by proxy. If my standards slip, their site slips.

This framing has a name in other professional contexts. A lawyer’s clients are not buying legal documents; they are buying the lawyer’s judgement applied to their situation. An accountant’s clients are not buying financial statements; they are buying the accountant’s judgement about what the statements should say. The professional’s reputation and the client’s outcomes are linked. The professional has a stake in getting it right because their own continued practice depends on it.

Hosting is not usually thought of this way, but for the kind of customer base I serve, it should be. The customer’s business reputation depends on my infrastructure judgement. If their site is hosted on a platform I would not be comfortable hosting on myself, I have failed them before any specific incident occurs.

The principle

The internal test I apply continuously is straightforward: would I be comfortable hosting my own business on this platform, with the current configuration, against the current threat landscape, with the current maintenance posture? If the answer is no, I have work to do.

This is a self-administered conflict-of-interest check. If I would not trust my own livelihood to the infrastructure as it stands, I cannot honestly host someone else’s livelihood on it. The standard is internal, continuous, and unconditional. It does not depend on whether any particular customer has noticed a problem or whether any particular incident has occurred. The infrastructure either passes the test or it does not, and if it does not, the response is to fix it rather than to wait for someone to complain.

This test does most of the work that “managed hosting” claims to do. If the operator is genuinely applying it, then the customer’s site is hosted on infrastructure that meets the operator’s personal standard for hosting their own work. If the operator is not applying it, then the customer is hosted on infrastructure that meets some lower bar (commercial viability, marketing claim, regulatory minimum) which the operator does not consider adequate for themselves.

The asymmetry of these two situations is the entire game. A customer hosted on infrastructure the operator considers good enough for their own use is structurally protected by the operator’s self-interest in maintaining their own service. A customer hosted on infrastructure the operator considers acceptable for customers but not for themselves is structurally exposed to whatever erosion the operator is willing to tolerate when it is not their own work at risk.

What this commits the operator to

Holding this standard is not a marketing position. It is a sustained operational discipline that affects every infrastructure decision. A few of the practical commitments that follow from it:

The infrastructure stack reflects considered choices, not inherited defaults. CloudLinux instead of stock cPanel on bare Linux, because CloudLinux properly isolates accounts and the cost of the licence is small compared to the consequence of a single compromised account taking down a shared server. Imunify360 instead of basic ModSecurity, because Imunify’s malware detection and remediation rules are materially better at catching the actual attacks customers face. KernelCare for live kernel patching, because the alternative is leaving known kernel vulnerabilities exposed for the days or weeks between patch release and the next scheduled reboot window.

These are not budget items. They are operational defences chosen because the underlying threats are real and the alternative is leaving customers exposed to incidents that could be prevented. The operator who would not host their own business on infrastructure without these defences cannot honestly host someone else’s business without them either.

Patches are applied on the actual threat timeline, not on a convenience schedule. When a high-severity CVE is published, the work to assess and apply the patch happens within hours, not within the next maintenance window. This is operationally expensive (it requires the operator to be available and to interrupt other work) but it is the only way the infrastructure stays at the standard the principle requires. A customer whose site is compromised through a vulnerability that was patched two weeks before the operator got around to applying it has been failed by the operator’s scheduling, not by bad luck.

Backups are verified, not just scheduled. A backup that has not been tested is a backup that may not work. JetBackup running daily is meaningless if no one has confirmed that a restore from those backups actually produces a working site. Backup verification is one of the recurring maintenance tasks that customers never see, but it is the difference between a real disaster recovery capability and an aspirational one. The operator who would want their own backups verified before they relied on them has to apply the same standard to their customers’ backups.

Monitoring catches problems before customers notice them. Disk utilisation trending toward capacity, memory pressure indicating a runaway process, abuse traffic patterns suggesting an emerging attack, mail server queue depth indicating delivery issues. All of these can be identified before they degrade into customer-visible incidents, but only if someone is watching the right metrics and responding to the right alerts. The operator who would want their own infrastructure monitored this way cannot leave their customers’ infrastructure unmonitored.

The same standard applies to the operator’s own infrastructure. The website you are reading is hosted on Momentum Hosting, audited by the same person who audits customer infrastructure, monitored by the same systems that monitor customer servers. If the principle is “would I be comfortable hosting my own business on this,” the test is verifiable by inspecting whether the operator does in fact host their own business on it. A hosting company whose marketing site runs on AWS or Cloudflare Pages or a third-party managed WordPress platform is implicitly admitting that their own product is not what they would choose for their own work.

The 3am alert

There is one specific commitment that distinguishes hosting that genuinely does not need the customer’s attention from hosting that pretends to: someone has to be paying attention twenty-four hours a day, because servers do not respect business hours.

Disk capacity issues, runaway processes, mail server reputation incidents, active attacks, backup failures, security alerts, network anomalies: any of these can fire at three in the morning, and any of them require human judgement to resolve before they degrade into something worse. If the response is “we will look at it when the office opens,” the customer’s site is unprotected for the intervening hours. If the response is “the on-call staff will follow the runbook and escalate if needed,” the customer’s site is protected only against the alerts the runbook covers, with everything else queued for daylight.

The boutique-scale provider handles these alerts without a tiered queue between the alert and a fix. There is no L1 to L2 to L3 path for an incident to climb. The people who configured the server and who know the customer’s site are the ones reading the logs at 3:07am.

This is not a feature most customers ever see, because by definition the customers who would notice are the ones who were protected from noticing. The site that was down for ten minutes overnight, instead of six hours, never produced a complaint because the customer was asleep and the problem was fixed before they woke up. The customer experiences this as their hosting “just working,” which is exactly what the marketing claim describes. The mechanism that produces it is a deliberate commitment to sustained, around-the-clock ownership, rather than a runbook handed down to the cheapest available tier.

This is the meaning of “hosting that does not need your attention” in operational terms. Attention is required; it is just not the customer’s attention that is required. The operator’s attention is required, continuously, at whatever hour the infrastructure demands it. The pricing reflects this commitment because the commitment is real and the work is real.

Attention is required. It is just not the customer’s attention that is required.

What the customer should expect

A customer being hosted on the boutique model should be able to point to specific operational practices their provider is following, not just marketing claims. The signals that distinguish genuine managed hosting from claimed managed hosting are practical:

The operator can describe their infrastructure choices and the reasoning behind them. “We use CloudLinux because of account isolation” is the right kind of answer. “We use industry-leading security” is the wrong kind. The first reflects considered judgement; the second reflects marketing copy.

The operator monitors their own infrastructure to the same standard as customer infrastructure. The status page is live, the monitoring is real, the response to incidents on the operator’s own systems is the same as the response to incidents on customer systems. If the operator’s own website is slow, compromised, or out of date, the operator is not applying their principle consistently.

A specific test worth applying: check the DNS configuration for the hosting provider’s own corporate domain. Anyone can do this with a public tool like intodns.com. A provider that markets DNS infrastructure as part of their service offering and runs their own corporate DNS on a third-party platform is making a visible operational decision that contradicts their marketing. The marketing tells prospects that the provider’s DNS is good enough. The provider’s own DNS choice tells you whether the provider believes their own marketing. There are Australian hosting companies that market “worldwide redundant DNS at no extra cost” and run their own corporate domain on Cloudflare’s free tier. The information is publicly verifiable, takes thirty seconds to check, and tells you more about the provider’s operational substance than their marketing page ever will.

For comparison, momentumhosting.com.au is served by ns1.momentumcluster.com and ns2.momentumcluster.com, on different subnets and different autonomous systems. The mail server is on the same cluster. This site is hosted on the same infrastructure stack we sell to customers, with the same operational standards applied. The intodns.com report for momentumhosting.com.au is publicly accessible and we invite you to read it alongside the corresponding report for any provider you are evaluating. The point of the recommendation is not just that we follow it; the point is that the recommendation is universally applicable and the answers it produces are diagnostic.

A second test is more telling, and more concerning. Many of the visible Australian hosting brands are not independent businesses. They are properties within international hosting groups that have acquired Australian operators over the past decade. When you evaluate one brand within such a group, you are evaluating the operational culture of the parent. The relevant diagnostic is to identify the parent group, find the other brands they operate, and examine those brands’ public-facing infrastructure with the same scrutiny you are applying to the one you are considering.

This produces uncomfortable findings. In the current Australian market, one of the largest international hosting groups operates multiple acquired Australian brands, plus a separate competing brand that sits on the same corporate balance sheet. The competing brand’s public marketing website is currently serving twenty-five to thirty hidden adult-content SEO spam links injected into the homepage HTML, between the navigation and the visible footer. The injection is contained within a <div style="display: none;"> element so the content is invisible to human visitors and visible to search engine and AI crawlers. The compromise has been present long enough for multiple independent observers to verify it, and a snapshot has been preserved in the Internet Archive in case it is later cleaned up. The corporate group has not detected this compromise on its own marketing site, or if they have detected it, they have not prioritised remediation.

The implications travel outward from this finding in two directions. First, the corporate group does not monitor its own customer-facing properties for the kind of compromise that any commercial malware scanner detects in seconds. Second, the operational culture that produces this result is the same operational culture that runs the hosting infrastructure their customers depend on. If the parent cannot keep its own marketing website clean of basic injection attacks, the case for trusting the same parent’s infrastructure with the customer’s website becomes difficult to make.

This is the substance of the principle in operational practice. The customer cannot inspect the hosting provider’s infrastructure directly. The customer can inspect the provider’s own public properties, which are run by the same people, with the same standards, applying the same level of attention. If those properties fail basic operational hygiene, the customer is being shown what to expect.

The operator can describe their incident response process concretely. Who responds to what, on what timeline, with what escalation path. If the answer is vague, the process is probably vague. If the answer is specific, the process is probably specific.

The operator’s customer base reflects the model they describe. A provider claiming to offer managed hosting whose customer base is full of self-managed developers is not actually operating in the segment they claim. A provider whose customer base is full of non-technical businesses who have been with them for years is operating in the segment they describe, because the customer base is the evidence.

The operator publishes reference content that demonstrates considered thinking. Marketing claims are cheap. Technical notes, security analysis, operational practice documentation, and considered writing about the work are signals of a provider who treats their practice as something worth describing carefully. A hosting provider whose entire web presence is sales pages and a contact form is probably operating closer to procurement than to professional services.

The customer relationship as the unit of work

The last and most important commitment of the model is that the customer relationship is the unit of work, not the ticket. A ticket is an event. A customer relationship is a continuing context that the operator carries in their head: what kind of business the customer runs, what their site does, what they have asked about in the past, what their tolerance for change is, what their actual technical level is, what their constraints are.

Operating this way means that any specific interaction with a customer happens against a backdrop of accumulated context. A new support ticket is not a fresh problem to be triaged; it is the next event in a relationship that has been running for years. The operator already knows whether the customer needs a careful explanation or a quick answer, whether they are sensitive to changes or comfortable with them, whether they prefer email or phone, whether the question is about something they will manage themselves or something they need handled on their behalf.

This kind of context cannot be transferred between staff members. It cannot be captured in a CRM. It cannot be scaled across thousands of customers per support agent. It only exists when the same hands have been working with a specific customer for long enough that the accumulated context is real and current. The boutique model is the only one that produces this context naturally, because it is the only one that keeps the same people and the same customer in continuous relationship for years at a time, rather than rotating them through a support roster.

The customer experiences this as hosting that knows them. The operator experiences it as a portfolio of customer contexts that they hold in their head and maintain over years. The pricing reflects the work because the work is real. The result is hosting that genuinely does not need the customer’s attention, because the attention is being given continuously by someone who has been giving it for years and intends to keep giving it.

This is what the marketing claim should mean. Most of the time it does not.