EnterraHost
We do not own the servers. We do not own the network they sit on, the building, the power or the fibre. Every uptime page in this industry is written by somebody who does, and the objection that follows is fair. If the metal is rented, what exactly are you promising.
The honest answer is a different model rather than a weaker one, and it survives only if the failures are published alongside the averages. So this piece is the model, the numbers we have measured, and the two days that went badly wrong.
What we rent, and what we own
The platform runs on infrastructure we do not own. That is a deliberate choice and it is not the interesting part. The interesting part is what sits above it, because that is where the work is.
We own the build of the servers, the operating system configuration, the web server and PHP pools, the mail stack, the DNS automation, the backup and restore path, the monitoring that checks every five minutes, the alerting that wakes us, and the promise attached to the invoice. When a site is slow because of a PHP pool setting, that is ours. When a certificate fails to renew, that is ours. When a database is corrupted by an application and the customer restores a snapshot from their own panel, that is our tooling doing the work.
What we do not own is the layer underneath. If the provider's storage degrades or a region loses power, we are a customer of theirs with the same ticket queue as anybody else, and no amount of monitoring makes that go away.
The numbers, with the method
Every domain in EnterraMon Pro is checked roughly 145 times a day from our own network and the results are summarised per domain per day. The figures below come from uptime_daily_summary, read on 10 November 2026, covering the window 14 June 2026 to 9 November 2026. The query summed checks rather than averaging daily percentages, because a day with 13 checks should not weigh the same as a day with 145.
| Measure | Result |
|---|---|
| Checks run | 123,313 |
| Checks that succeeded | 123,045 |
| Checks that failed | 268 |
| Uptime across all of it | 99.783 percent |
| Domain days recorded | 814 |
| Days that were not perfect | 34 |
99.783 percent is not a headline. It is one failed check in 460, and it is the number we would be asked to explain if a customer added up their own month and got something worse.
The two worst days, and what they were not
The worst day in the window is 20 July 2026 on one domain, which answered 13 checks out of 145 and finished at 8.97 percent. The tempting sentence here is that the site was down. It was not, as far as anybody can tell. It was almost certainly us working on code, which is the same failure from the customer's side and a completely different problem from ours.
That distinction is the whole reason this section exists, and it is also the reason this article cannot settle it. uptime_daily_summary stores counts, not causes. It records that 132 checks failed. It does not record whether the web server was restarting during a deploy, whether a provider was moving a volume, or whether a PHP fatal was serving 500s for six hours. Anyone telling you which of those it was from this table alone is guessing.
The pattern is at least consistent with work on our side. A provider incident tends to take out every domain in a region at once. On 20 July every other domain answered 145 of 145 checks, so the platform was healthy and one site was not, which is what a change to one site looks like.
On 24 July 2026 two domains answered 123 of 145 and 123 of 144 checks, landing near 85 percent, and one was still at 88 percent the next day. Two domains failing together is a different shape again, and the honest answer is that the record does not say why.
Across 814 domain days, 34 were not perfect. Six finished below 95 percent. The rest were a handful of failed checks in a day, which is what a single five minute blip looks like when you count 145 of them.
What that means for the model is the useful part. A platform we own would have the same problem, because a deploy is a deploy on any hardware. Buying the metal buys control of the failure. It does not buy the absence of one, and most uptime pages are written as though it does.
Where the risk actually sits
Three layers, and it is worth being precise about which one fails.
What we control. The application stack, the configuration, certificate renewal, DNS records we manage, the backup path, the monitoring, and the response when something is wrong. Most of what a customer experiences as the host being good or bad lives here.
What the provider controls. The physical host, the storage, the hypervisor, the regional network and the scheduled maintenance windows. We can see these fail and we cannot stop them failing. What we can do is choose providers with published terms, keep the platform rebuildable, and tell the customer what happened.
What neither controls. The route between a visitor and the region. A site that is up everywhere can be unreachable from one country because a transit provider is having an afternoon. That is also why monitoring from one place is nearly useless and why every check we publish runs from more than one.
Why this is not the weaker option
Renting has three advantages that a small operator on owned hardware cannot match, and they are not marketing points.
Capacity arrives in the hour it is needed. An upgrade is a plan change rather than a purchase order. A customer who outgrows a plan does not wait for a quarter.
There is no capital to recover. A server that cost money depreciates whether or not anybody buys a plan. Rent is spent against demand, which is why a small provider can be competitive on price without being cheap on the platform.
The platform is portable by design. Nothing in our stack assumes one provider's API. That is also the honest answer to the obvious follow-up question about what happens if the provider disappears.
And the comparison should be stated the other way round too. An operator who owns the hardware has a failure mode we do not, which is hardware they bought three years ago and can no longer afford to replace.
The counterargument
The strong case against this model is dependency. One provider means one outage window, one support relationship, one set of regional limits, and a maintenance schedule somebody else chooses. A customer who needs a written guarantee tied to metal will not get it here, and should not be told otherwise.
The second objection is that "it was the provider" is not an answer a customer wants to hear. That is fair as well. The provider is our supplier, not our excuse, and the only useful reply is what changed afterward.
What we have done instead of promising the impossible is make the failure visible and the recovery short. Roughly 145 checks a day per domain. Alerts that reach a person rather than a dashboard. A public status page with the components listed separately, including the ones that are not ours to fix. A refund commitment on uptime, which is a financial answer rather than a technical one. And a restore path a customer can run themselves, so a broken file does not wait for us to be awake.
That is the trade. We cannot promise the hardware, and we cannot promise that our own changes never break a site for an afternoon. We can promise that we will know within five minutes, tell you what happened, and make the recovery quick.