Summary

  • NovaCloud-Hosting's public website resolves through Cloudflare nameservers and Cloudflare-fronted A records, while its mail runs on the operator's own nc-h.com namespace — a split between third-party DNS authority and operator-controlled infrastructure that the storefront does not mention.
  • The operator maintains two separate Instatus status pages, novacloud.instatus.com and novacloud-hosting.instatus.com, for the same brand, each carrying its own component list and incident history.
  • The operator's own incident records document a major FFM2 outage running from 20 July to 8 August 2026, roughly 19 days, with staggered per-service recoveries and a self-reported attribution chain reaching through upstream PletX filtering to a legal dispute inside the NTT FRA1 datacenter.
  • Third-party ASN data reports 1,206 hosted domains across 415 IP addresses, 4,352 IPv4 addresses, 8 peers and no measured IP addresses geolocating to Portugal, despite the operator's Portuguese registration.
  • Announced prefix space under AS209874 is attributed to three different organisations — Tech Tide Portugal, NovaCloudHosting and a third party, KEKSHOST SRL — complicating any single-brand infrastructure identity.

A small hosting brand can be examined at several layers. Prior BTW reporting on Novacloud — the hosting and IP-transit brand operated by Portugal's Tech Tide Portugal Unipessoal LDA under autonomous system AS209874 — has covered its routing mirrors, its registry accountability surfaces, its transit dependency structure and its commercial-legal paperwork.

This article assembles a layer none of that coverage put together: the service-operations evidence, meaning what the operator's own status pages, its DNS configuration and third-party measurement services say about how the service customers actually buy is constituted, monitored and delivered.

The evidence reviewed here is drawn entirely from public sources captured on 4–6 October 2026 through provider-reported search snapshots: the operator's own status pages on the Instatus platform, its storefront imprint and about pages, its ASN marketing site, a DNS aggregation service, third-party ASN databases, a community forum reproduction of an operator customer email, and a documentation subdomain. Where a claim rests on the operator's self-reporting, this article says so; where it rests on third-party snippets rather than live queries, it says that too. Nothing here is a verdict on the operator's viability.

It is a map of what a customer, a downstream network or an abuse reporter can actually reach when they try to verify what NovaCloud-Hosting claims.

The DNS authority split

The most concrete piece of infrastructure evidence in this layer comes from a DNS aggregation view of novacloud-hosting.com. According to host.io's record snapshot, the domain's nameservers are alaric.ns.cloudflare.com and hazel.ns.cloudflare.com, its A records sit in Cloudflare proxy ranges (104.26.6.194, 104.26.7.194, 172.67.75.83, with matching Cloudflare IPv6), and its MX records point at mgw-01.nc-h.com and mgw-02.nc-h.com — hosts under the operator's own nc-h.com namespace. The storefront itself is reported to sit at approximately 5.231.25.28 under AS209874.

Read together, those records describe a deliberate architecture: the customer-facing web tier is fronted by a third-party CDN/DNS provider, while the mail system and, presumably, the hosted services run on infrastructure the operator controls. This is common practice and not inherently a criticism. What makes it editorially relevant is the gap between the architecture and the marketing. The operator's About page claims it "runs its own network under the autonomous system AS209874", giving "direct control over routing, peering, and connectivity between its locations". A customer reading that would not learn that the most visible surface of the brand — its own website — is served from Cloudflare's nameservers and proxy network, not from the network the page describes.

The mail namespace is the more interesting half of the split. The imprint at novacloud-hosting.com/imprint ties nc-h.com, nc-h.cloud, novanetwork.net, as209874.net, freeminehost.com and glowberry.gg to the same legal entity, Tech Tide Portugal Unipessoal LDA, with Faro company register 517354420 and VAT number PT517354420. So the nc-h.com mail hosts are operator-controlled in a real sense — but the domain set itself spans two namespace families (novacloud-hosting.com and nc-h.com), and the brand's accountability layer, as prior BTW coverage documented, distributes contact functions across three email addresses on two domains. The DNS layer reproduces that pattern: authority divided between a third party and the operator, with no single point where a reader can confirm both ownership and control.

Two status pages for one brand

Service monitoring is where the operator's public evidence becomes genuinely unusual. The operator runs not one but two separate status pages on the same third-party platform. The first, novacloud.instatus.com, shows a per-component status list at read time — Website, Dashboard, Control Panel, Game-Panel, Dedicated-Server Management, SkyLink Data Center, Game-Cloud Infrastructure, VPS Hypervisor EYG1, Dedicated-Server EYG1, Domains, NBG Datacenter, VPS Hypervisor FFM2, Dedicated-Server NBG1, FFM2 IP-Transit, Proxmox-Backup-Servers (with a reported 99.85% uptime), and an FFM2 Datacenter (NTT-FRA1) entry with an uptime graph. The second, novacloud-hosting.instatus.com, documents a separate incident set with its own affected-component list: IP-Transit FFM2, Standard VPS DE, High-End VPS DE, Dedicated Servers FFM2 and Colocation Services FFM2.

Two parallel status pages for one brand raise a question a customer cannot answer from the outside: which page is canonical, and are incident records consolidated anywhere? An incident that appears on one page with certain timestamps may appear on the other with different timestamps and different component names. The history index of the second page extends into August 2026 and shows mixed component states during the outage window — IP-Transit FFM2 listed as operational while Standard VPS DE, Dedicated Servers FFM2 and Colocation Services FFM2 were marked major outage. A reader comparing the two pages during the incident would have seen different, partially contradictory pictures of the same infrastructure.

The component lists themselves are informative. The codes EYG, FFM2 and NBG correspond to Eygelshoven, Frankfurt and what appears to be a Nuremberg site — the three locations the About page markets. The status infrastructure tracks per-hypervisor and per-datacenter availability, which is more granular operational disclosure than many small hosts offer.

But the reported 99.85% uptime figure for Proxmox-Backup-Servers is a non-round number in the operator's own data, and the headline "All systems operational" state coexists with a documented multi-week major outage in the same incident history — a reminder that a status headline is a point-in-time snapshot, not a service-level statement.

The FFM2 outage: what the operator's own record shows

The central incident in this layer is the FFM2 outage documented on the operator's own incident page. According to the incident record, a major outage began at 8:05 AM UTC on 20 July 2026 and was marked resolved at 2:00 PM UTC on 8 August 2026 — 19 days. The timeline is staggered by component: NBG Datacenter, VPS Hypervisor FFM2 and the RYZEN-01 through 04 VHOST-DE Gen-3 hosts transition through major outage, operational, partial outage and back to operational at different times, rather than a single all-clear.

The operator's own updates attribute the disruption in two stages: first to upstream PletX "blocking GRE packets from multiple source IPs", then to "false filtering of PletX, which dropped TCP connections". IP-Transit and High-End VPS DE were reported restored while Dedicated Servers and Standard VPS DE still awaited resolution "from our infrastructure provider at the NTT-FRA1 datacenter".

A second incident record on the other status page, dated 17 July 2026 with a start at 3:27 AM UTC and uneven per-component restore times (some restored at 10:28 AM, others listed as down until 12:00 AM), predates the main incident and suggests the disruption window opened days earlier than the "major outage" start date.

A third source fills in the attribution chain and the customer-impact detail, with a caveat. A LowEndTalk thread reproduces what is presented as an operator customer email: a legal dispute between the operator's contractual colocation provider and that provider's upstream rack operator inside NTT FRA1; physical systems for Standard VPS DE unavailable from 09:55 on 20 July with no physical access to servers or live storage; recovery onto replacement infrastructure in the Netherlands; Frankfurt restoration expected by 7 August; credits plus seven free days offered; and a request that affected customers not pay open invoices. The thread also cites a future Frankfurt routing plan built on PletX with two redundant 40 Gbit/s links plus two backup 10 Gbit/s links.

Every element of that account is the operator's own framing, reproduced by a third party and unverifiable from the outside — the legal dispute, the access denial, the credit terms. What the status pages independently corroborate is the duration, the staggered recovery and the dependency on an upstream provider at NTT FRA1. What no public source independently confirms is the cause. This article therefore treats the legal-dispute attribution as a claim made by the operator, not as an established fact.

The operational significance is structural, not forensic. A hosting operator whose flagship datacenter service can be cut off from physical access for nineteen days because of a dispute two contractual hops away is dependent on a chain it does not control. That is normal for small hosts; what is unusual here is that the dependency is documented in the operator's own incident records, while the marketing layer claims "direct control".

The measured footprint

Third-party measurement data adds an external check on scale. IPinfo's ASN view reports 1,206 hosted domains across 415 IP addresses, 4,352 IPv4 addresses, ASN type Hosting, registry RIPE, allocated 24 April 2025 and updated 26 February 2026, with 8 peers — and, notably, that "this network is registered in Portugal but has no measured IP addresses geolocating there". For a brand whose identity is anchored in Portuguese registration, the absence of any Portuguese-geolocated address space is a measurable divergence between legal identity and operational geography.

IPregistry's snapshot corroborates the Tech Tide Portugal identity and the address count, and adds a prefix-level breakdown: several /24s under Tech Tide Portugal, three (165.217.161.0/24 through 165.217.163.0/24) under "NovaCloudHosting", and 194.62.122.0/24 under "KEKSHOST SRL" — a third-party organisation name inside the AS's announced space. The announced-space holder names thus span three organisations. Prior BTW coverage established the registry-side identity gaps around the novacloud-admin handle; this layer shows the same fragmentation reproduced in the address space itself.

The hosted-domain figure deserves its own note. 1,206 domains across 415 IPs is a real, non-trivial customer footprint — consistent with a working small hosting business, not a shell. The evidence in this article does not support any claim that the operator is not serving customers; it supports a claim about how thinly or thickly the accountability and status layers describe that service.

The docs layer

A final, thin piece of evidence is the operator's documentation subdomain, docs.novacloud-hosting.com, which surfaces references to IP Transit, NetBird, monitoring and uptime tooling, and storage and configuration guides. It corroborates that the brand maintains a technical-documentation surface, consistent with the status-page practice documented above. The available snippet contains no hard records or dates, so this article uses it only as corroboration of the service layer's existence, not as evidence of any specific practice.

What the service layer adds up to

Assembling the layer: a web tier fronted by a third-party CDN while mail and hosting run on operator infrastructure; two parallel status pages whose incident records are not consolidated; a 19-day outage with staggered recovery and a self-reported, externally unverifiable cause chain; a measured footprint of roughly 1,200 hosted domains with no Portuguese-geolocated space; and announced prefixes held under three different organisation names. Each element alone is ordinary for a small host. Assembled, they describe an operator whose service evidence is more fragmented — and in places more revealing — than its storefront.

The interpretation this article supports is not collapse or failure. The operator served and, on the evidence available, still serves real customers; its status infrastructure shows more per-component granularity than many peers; and it offered credits and communicated through a documented incident. The finding is narrower: the auditable service layer lags the marketing layer, and the divergence is systematic enough that a customer or downstream network should verify claims — DNS authority, status-page canonicality, datacenter dependency — against measured evidence rather than the About page.

Prior BTW coverage showed the same pattern in routing, accountability and legal layers; the service layer repeats it in a different register. That repetition, across four independent layers of public evidence, is the story.

Sources: as209874.net · RIPEstat AS209874