Summary
- AS30344 is active rather than merely registered. On July 15, 2026, RIPEstat showed four IPv4 /24 announcements and one IPv6 /40; the newest IPv4 block, 23.26.1.0/24, was assigned to 365.hosting on May 6 and appeared in routing data on May 7. All four IPv4 origins validated under RPKI in the reviewed snapshot, while the IPv6 route returned an unknown validation state.
- Public route observations showed one neighbour, MIRhosting AS52000. That is meaningful concentration at the visible AS boundary, even though MIRhosting itself has multiple upstreams, exchange connections and facilities. No published evidence proves a second AS30344 transit, physically diverse entrances, tested failover or equivalent replacement capacity.
- 365.hosting sells VPS and dedicated servers in the United States and the Netherlands and says it uses its own racks in Tier III data centres. Its US copy still identifies the Secaucus site as vXchnge NJ01, although H5 Data Centers now lists the same 200B Meadowlands Parkway facility. Its Dutch VPS page contains legacy WebHOST1 text claiming WebHOST1 equipment at Serverius; Kolo's transition page says Serverius is now operating under the Kolo name, whose current portfolio has four Dutch sites. Neither surface identifies the relevant 365.hosting rack or Kolo site. Rack count, installed IT load, available inventory, occupancy, power entitlement and cross-site restore capacity remain undisclosed.
A 256-address addition makes the network easier to see
The most useful way into 365.hosting is not its home-page promise of premium data centres. It is a small, dated change in the public address registry. ARIN's record for 23.26.1.0/24 says the 256-address block was assigned to 365.hosting on May 6, 2026. A RIPEstat history query shows AS30344 announcing it from May 7. The sequence is unusually clean: assignment one day, visible route the next.
That new block matters because it confirms current network activity without requiring a customer testimonial or a promotional launch. By the July 15 snapshot, the announced-prefix view contained four IPv4 /24s: 23.26.1.0/24, 23.152.200.0/24, 77.91.126.0/24 and 138.124.187.0/24. It also contained 2602:2d3::/40. The IPv4 total is 1,024 addresses. The IPv6 /40 is a routing allocation, not a count of servers, customers or usable virtual machines.
The same snapshot also sets the first limit on the story. RIPEstat's AS-neighbour view found one left-side neighbour, AS52000. IPinfo's AS30344 page likewise classified MIRhosting as the sole upstream and called AS30344 a stub network. A stub is an AS that originates its own routes but is not observed providing transit to downstream networks. This is an operationally coherent shape for a modest hosting network. It is not proof of route diversity.
The correct opening assessment is therefore neither “paper network” nor “proven resilient cloud”. AS30344 is active, its address space is reachable and new resources have been put into routing. But its publicly visible exit from the AS remains concentrated. That distinction will matter whenever the sales site promises high availability, multiple countries or round-the-clock service.
The brand sells more than AS30344 can describe
The 365.hosting home page presents a conventional but broad infrastructure catalogue. It lists VPS/VDS, dedicated servers, domains, SSL certificates, server administration and security add-ons. It says the business has operated since 2022, has locations in the United States, Europe and Asia, uses “own racks” in Tier III facilities plus partner sites, supports more than 20,000 projects and belongs to the international 365.partners group. It also displays larger marketing counters, including active websites and a five-year 99.9 percent uptime claim.
Those statements establish what the brand wants customers to buy. They do not allocate physical assets to AS30344. The claim of own racks does not name rack IDs, leases, facility halls, power feeds or the company that holds title to the servers. The project and website counters do not explain whether they cover 365.hosting alone, the older WebHOST1 platform, the 365.partners group, domain registrations, dormant accounts or live paid compute. The uptime figure does not publish a measurement period, service denominator, maintenance exclusions or incident log.
The product pages are more tangible. The US dedicated-server page listed dual-socket Intel configurations, one IPv4 address, 30 TB of traffic, a nominal 1 Gbps channel for the standard offer, a five-to-ten-day setup time and free initial administration. It also displayed a higher-end configuration with a 10 Gbps channel. The Netherlands dedicated-server page similarly offered a dual-Xeon system, NVMe storage, one IPv4 address, 30 TB of traffic, a 1 Gbps channel and the same setup interval.
This is evidence of a staffed storefront and defined products. It is not a live inventory report. A plan card can remain online while a chassis is on order, a rack is full, a price is stale or a location is temporarily unavailable. The five-to-ten-day setup time is especially revealing: dedicated capacity is not necessarily an instantly provisioned pool. It may depend on technicians, spare parts, remote hands, server assembly, burn-in, cabling and address assignment. The product is a promise to deliver hardware after an interval, not proof that every advertised configuration is installed and idle today.
The network and catalogue must also be kept separate. A customer's server could use AS30344 space, another group ASN, facility-provided addresses or an upstream's allocation. Conversely, an AS30344 address may host infrastructure that is not sold under the current US or Dutch product card. Without a published mapping between service, prefix, facility and contract, the ASN is the clearest network identity but not a complete inventory of the commercial platform.
Sheridan is the registry address, not the server room
The ARIN autonomous-system record names 365-HOSTING, marks AS30344 active and ties it to organisation handle PARTN-46. The associated ARIN organisation record gives 30 N Gould Street, Suite R, Sheridan, Wyoming, and the 365.hosting support address. The company's contact page repeats the same Wyoming address and telephone number.
This makes Sheridan a strong administrative and registry location. It does not make it a data-centre location. There is no facility claim on the contact page, no power or cooling description for Wyoming, and no public route measurement placing the server estate in that building. Treating a registration address as a rack coordinate would collapse legal presence and physical operations into one unsupported point.
The domain record adds a different timeline. The CentralNic RDAP response for 365.hosting records the domain's creation in July 2022 and names ns1.365.hosting and ns2.365.hosting. Public DNS on July 15 resolved the site to 23.152.200.43, within an AS30344 prefix. The mail and name-service hostnames also sit inside addresses associated with the same network. This gives the brand a direct technical relationship to AS30344, stronger than an aggregator simply matching a name.
Yet even this does not establish the corporate chain with precision. The home page says 365.hosting is part of 365.partners. The RIPE NCC member page for 365.partners INC gives the same Sheridan address, phone number and a 365.hosting email domain, and lists service areas in Germany, the United Kingdom, Israel and the Netherlands. IPinfo's AS198178 page associates that larger 365.partners network with 365.hosting and shows a substantially broader address footprint than AS30344.
Those common identifiers support an operating affiliation as publicly represented by the brand and registries. They do not justify merging AS30344 and AS198178, assigning every group prefix to this directory entity, or assuming that one ASN is an automatic backup for the other. Separate route origins can share contacts and commercial control while using different upstreams, facilities and operating policies. A recovery claim needs a stated failover design, not merely a related name.
The four IPv4 blocks do not share the same registry history
The 1,024 IPv4 addresses originated by AS30344 look uniform in a route table: four equal /24s. Their registration histories are not uniform. That difference is a useful warning against treating routed space as a single owned pool.
ARIN directly allocated 23.152.200.0/24 to 365.hosting in May 2023. The newer 23.26.1.0/24 is an assignment from a larger parent block, registered in May 2026. The RIPE database entry for 77.91.126.0/24 names the network Webhost_LLC, describes 365.partners INC in the remarks and carries the same Sheridan contact. The RIPE entry for 138.124.187.0/24 names Webhost LLC in Moscow and says the subnet is used to provide virtual and dedicated servers that are self-managed by customers.
These records support an operating picture in which 365.hosting originates a mixture of directly allocated, assigned and group-related address resources. They do not prove ownership of all four blocks in the ordinary property sense. Internet number resources are administered under registry policies and can be reassigned, sub-allocated or routed under agreement. The different organisations and remarks are part of the control boundary, not a clerical nuisance to erase.
Reverse DNS gives limited evidence of use. IPinfo's view of 23.152.200.0/24 showed most addresses with webhost1.net static names and identified ns1.365.hosting, ns2.365.hosting and the main 365.hosting hostname. Its 77.91.126.0/24 view included vm.365.hosting amid similar webhost1.net naming. The 138.124.187.0/24 view showed mail.365.hosting and more WebHOST1-style reverse records.
This is strong evidence that the brand and older WebHOST1 operating environment share a control surface. It is weak evidence for individual customer identity, server count or physical location. Reverse names can persist after moves, be generated automatically, or point to a management convention rather than a building. They should not be converted into an inventory of 1,024 live servers.
Route authorisation is better than route redundancy
The four IPv4 announcements had a useful security property at the reviewed timestamp. RIPEstat's RPKI validator returned valid for 23.152.200.0/24, 23.26.1.0/24, 77.91.126.0/24 and 138.124.187.0/24 when originated by AS30344. That means relying networks using route-origin validation had cryptographic authority to accept this ASN-prefix pairing.
The IPv6 route was different. The validator returned unknown for 2602:2d3::/40 because it found no validating ROA in that response. Unknown is not invalid. It means route-origin validation supplied no positive authorisation for that pair. The distinction matters for security posture, but neither a valid nor unknown state says anything about bandwidth, congestion, facility power or customer failover.
RPKI is therefore a routing-integrity control, not a redundancy mechanism. A perfectly authorised route can still disappear when a router fails, a transit contract lapses, a fibre is cut or a maintenance change goes wrong. It can remain visible yet suffer packet loss. Conversely, a route with one visible neighbour can inherit considerable reach from that neighbour's global network, but it still depends on the commercial and technical handoff between the two systems.
The public topology supports caution rather than alarm. Route collectors do not observe every private interconnection, and a backup session may be configured but inactive. A second carrier may also exist at Layer 2 while AS52000 remains the only BGP neighbour. The evidence cannot prove there is no hidden or cold standby. It can prove that no second AS neighbour was visible in the July 15 RIPEstat view and that the company had not published a test demonstrating one.
MIRhosting is a substantial network, but it remains the visible hinge
AS52000 is not a small single-carrier endpoint. MIRhosting's company page lists more than ten data-centre locations across Europe, the United States and Asia, including Secaucus and 60 Hudson Street in New York, several Dutch sites, Frankfurt and Mumbai. PeeringDB's AS52000 record describes a global network with 1-5 Tbps of traffic, an open peering policy, multiple exchanges and facilities, and 24-hour NOC and abuse contacts. BGP.tools lists several upstreams, including Arelion, GTT, Cogent and Tata, alongside exchange connections.
That breadth reduces the temptation to equate “one AS neighbour” with “one physical cable to the whole internet”. MIRhosting can carry AS30344 over a network with its own redundant routers, upstreams and sites. The IPinfo traceroute sample reached an AS30344 address through a MIRhosting router identified near New York, consistent with a US service path. Yet this does not disclose how many ports join AS30344 to AS52000, whether those ports enter different buildings, or whether Dutch and US services use separate handoffs.
The hinge remains real. If every externally visible path for AS30344 depends on AS52000 accepting and propagating its routes, then a policy error, commercial suspension, route leak filter, DDoS response or shared control-plane failure at that boundary can affect all four IPv4 prefixes and the IPv6 prefix together. MIRhosting's upstream diversity does not automatically protect against a failure specific to the AS30344-AS52000 relationship.
Customers need a more precise answer than the word “redundant”. Useful proof would include a second active transit AS, route-collector history showing both paths, separate facility cross-connects, port capacity, failover test dates and evidence that service prefixes remain reachable after either handoff is disabled. None of that was found in the public material reviewed for this profile. The network should therefore be described as active and globally reachable, with only one publicly observed upstream relationship.
The Secaucus label has outlived the operator
The United States product is physically specific in one respect. The 365.hosting New Jersey announcement, dated March 7, 2026, says its NVMe cloud servers are in “vXchnge Secaucus” and describes a 54,121-square-foot facility near New York City. The dedicated-server page calls the site vXchnge NJ01. This gives customers more than a generic “USA” region: it points to Secaucus, New Jersey.
The operator name is stale, but the public acquisition date itself needs a caveat. H5's live acquisition announcement is dated January 31, 2021, while Data Center Dynamics' contemporaneous confirmation is dated January 31, 2022. The one-year source conflict prevents a more exact age claim; both dates still precede the 365.hosting March 7, 2026 launch notice by at least four years. The current H5 facility page lists its New Jersey data centre at 200B Meadowlands Parkway, Secaucus, describes it as a Tier III facility of more than 38,000 square feet and markets it for New York business continuity. PeeringDB's facility record calls it H5 Data Centers Secaucus (NJ01), gives the same address and preserves “vXchnge Secaucus (NJ01)” only as an alternate historical name.
The mismatch does not prove that 365.hosting's servers left the building or that service is unavailable. A customer agreement and rack can survive a facility sale. It does show that the company's public description has not been updated to the current operator. That weakens confidence in adjacent claims that are harder to check, such as which party provides remote hands, what service-level agreement applies, who receives an escalation during a facility incident and whether the quoted 54,121 square feet describes building footprint, former marketed area or current sellable space.
It also changes the contractual dependency. If H5 now controls the site while 365.hosting controls servers or racks and MIRhosting supplies the visible network path, then a customer depends on at least three operating layers. H5 maintains building access, power, cooling and facility procedures. 365.hosting provisions and supports the server service. MIRhosting carries the visible BGP relationship. Additional hardware suppliers, payment processors and management platforms sit behind those layers. No public contract reviewed here shows which layer owes the end customer a remedy when two layers disagree about the cause of an outage.
The safest location statement is narrow: 365.hosting publicly markets US servers in a Secaucus facility historically known as vXchnge NJ01; H5 currently presents the 200B Meadowlands Parkway site as its New Jersey facility. Public evidence does not identify 365.hosting's rack, installed load, cage, current cross-connects or remaining sellable capacity inside it.
The Dutch location is named only to the facility group
The Netherlands offer is similarly real but less geographically precise. The 365.hosting Netherlands launch notice, also dated March 7, says virtual servers became available in a Serverius data centre. The Netherlands VPS page contains legacy WebHOST1 copy: it says WebHOST1 offers the service and uses its own equipment in a Serverius data centre. That is a WebHOST1 claim exposed on the 365.hosting surface, not proof that 365.hosting owns the equipment. The page also describes KVM virtualisation, SSD storage with RAID10, a 100 Mbps plan channel and a 30-day refund. The dedicated-server page raises the advertised channel to 1 Gbps for its listed hardware.
Serverius is also no longer the current standalone public label. Kolo's transition page says Serverius and Fuzion are now operating under the Kolo name, with the same locations and services, and says the unified brand officially goes live on July 17. Kolo's Netherlands portfolio lists four sites: NL1 Dronten, NL2 Meppel, NL3 Apeldoorn and NL4 Amsterdam. Those are Kolo platform claims, not a map of 365.hosting equipment. The 365.hosting page does not say which facility, room or rack holds the relevant service, and no public cross-connect record ties AS30344 to a specific Kolo site.
That missing site identifier limits both locality and recovery analysis. A customer choosing “Netherlands” can reasonably expect data processing in the country when the service is operating as marketed. The public page does not disclose whether backups remain in the same building, another Serverius site, the United States or a management platform elsewhere. It does not say whether a failed Dutch host can be restored in Secaucus, whether customer consent is required for such a move, or how long image and data transfer would take.
The NOC notices still served on the Serverius domain illustrate why these distinctions matter and already use KoloDC labels. In 2026 the site published cooling maintenance at NL1 Dronten and dark-fibre work between NL1 Dronten and NL2 Meppel, explaining that alternate fibres should take over while warning of possible latency or packet loss during route reconvergence. That is healthy operational disclosure by the facility network. It does not prove that 365.hosting occupied either affected site or participated in the alternate path. It simply shows the type of physical maintenance that a “Netherlands” label hides.
The Dutch evidence grade is therefore medium for country-level service availability and weak for exact asset placement. The product pages make the offer credible, while the Serverius-to-Kolo transition establishes the current facility-platform identity without locating the service. The sources do not establish a street address, installed inventory, power entitlement, rack ownership or cross-site replication for 365.hosting.
Capacity cards are not a capacity statement
The storefront publishes useful commercial units: processor type, memory, disk, channel, traffic allowance, IPv4 count, setup time and billing period. These are customer entitlements if supplied under the applicable contract. They cannot be added together to calculate the provider's capacity because the site does not publish the number of available servers or virtualisation hosts behind each card.
One Dutch VPS plan was displayed as out of stock when reviewed. That is a small but valuable operating signal. It suggests the catalogue can expose an availability state rather than accepting every configuration without limit. It also demonstrates why a plan specification is not installed capacity. A 20 GB disk entitlement and a 100 Mbps port on an unavailable plan provide no usable service to a new customer.
The dedicated-server pages state a five-to-ten-day setup time. This can represent normal provisioning rather than shortage, but it exposes the role of hardware inventory and labour. If a production server fails, the relevant question is not whether a matching SKU exists on the website. It is whether an equivalent chassis, memory set, NVMe device, power allocation and technician are available at the same site under an agreed replacement objective.
No reviewed page disclosed rack count, server count, hypervisor count, aggregate CPU cores, installed storage, spare-drive stock, powered capacity, committed bandwidth, oversubscription, sold percentage or reserved inventory. The home-page claim of own racks remains unquantified. H5's facility size and the Kolo platform's scale belong to those facility operators; they cannot be assigned to 365.hosting. A tenant can occupy one cabinet in a large data centre, and the size of the building says nothing about the tenant's free capacity.
Even the 1,024 routed IPv4 addresses are not a server limit. One host can carry many addresses; one address can front many virtual hosts; addresses can be reserved, routed but unused, used for network appliances or assigned to customers. The IP2Location AS30344 summary corroborates the four /24s and single MIRhosting upstream, but its address total is a network-resource measure, not a compute measure.
The capacity conclusion is therefore explicit: current offerings and routed resources demonstrate an operating service, but installed, sold, spare and failure-condition capacity are not publicly quantified. Any stronger number would be invented.
A 99.9 percent claim needs a denominator
365.hosting's home page says it achieved 99.9 percent uptime over five years, even though the same page says the brand has operated since 2022. By July 2026, a full five-year measurement under that brand would extend before the stated operating date. The figure may include an older WebHOST1 service history, may be rounded marketing copy, or may use another start point. The page does not explain the denominator.
At 99.9 percent, arithmetic allows about 8 hours and 46 minutes of downtime in a 365-day year if measured continuously. That calculation is not evidence of actual downtime. It only shows why scope matters. Website availability, control-panel availability, network reachability, VM power state and application response can each produce a different percentage. Planned maintenance, force majeure and customer-caused incidents may be excluded from a contractual SLA even when they remain visible to users.
The public technical-works page did not present a clear English incident archive in the reviewed view. The contact page says customers get the fastest response through the billing-panel request system and separately mentions an online support chat from 9 a.m. to 9 p.m., while broader pages advertise 24/7 support. These statements can coexist if tickets are monitored around the clock but chat is not. They do not publish initial-response or restoration targets.
Without an incident history and service-specific SLA, the uptime claim should remain attributed. It cannot be used to infer that both countries, every product, AS30344 or the management platform achieved the same result. It also cannot demonstrate recovery from the failure modes most relevant here: losing AS52000, losing a rack power feed, replacing a dedicated server, restoring a customer image or moving a workload across borders.
Useful operating disclosure would publish service availability by region, maintenance exclusions, incident start and end times, affected components, root cause, remediation and whether contractual credits were issued. That evidence was unavailable. The absence does not mean outages occurred. It means the advertised percentage cannot carry the analytical weight of a measured reliability record.
The control plane reaches back into WebHOST1
The public site exposes a second concentration that is easier to miss than BGP. Its home-page HTML preconnects to api.webhost1.ru, its content and navigation reuse WebHOST1 routes, and large parts of its product data and management references carry WebHOST1 hostnames. The reverse DNS across AS30344 also repeatedly uses webhost1.net. The 365.hosting sitemap points at webhost1.ru pages rather than a clean, brand-specific set of URLs.
This supports continuity with an established operating platform. It may allow 365.hosting to reuse billing, provisioning, support knowledge and server-management systems rather than building them from zero. It also creates a failure and governance boundary. A customer can have a running VM whose public packets flow through AS30344 while still depending on another domain and platform for ordering, payment, password reset, tickets, console access or automation.
The 365.hosting document page displayed links for a public offer, account load limits and personal-data terms, but the reviewed English page did not expose a complete, readily auditable company name and service schedule. The contact page's banking-details section also appeared unfilled in the rendered English view. That makes it difficult to determine from the public English surface which exact legal entity invoices a customer, which terms govern the US and Dutch products, and whether Webhost LLC, 365.partners INC or another affiliate performs a particular obligation.
This is not evidence that contracts are absent; customers may receive complete terms during checkout. It is evidence that an outside customer cannot verify the complete contracting chain before entering the private purchase flow. For data sovereignty, incident escalation and insolvency planning, that distinction matters. The party operating the control panel may not be the party holding the rack lease or the party originating the route.
A robust exit plan must account for both planes. Data backups without credentials, images, DNS zones and domain-transfer access may not be enough. Conversely, control-panel access is of limited value if the only copy of customer data remains on unavailable storage. Public material does not specify export formats, API guarantees, account handover procedures or emergency access if the normal platform fails.
Failure begins where ownership changes hands
The first failure path is the visible route boundary. If AS30344 loses its relationship with AS52000, all five observed announcements could become unreachable together unless an undisclosed alternate takes over. Customers using addresses originated elsewhere might behave differently, which is why service-to-prefix mapping matters. The public record does not provide it.
The second path is facility-specific. In Secaucus, H5 controls the building layer now attributed to a historical vXchnge name. In the Netherlands, the offer still says Serverius while the public facility platform is moving under the Kolo name, and the exact site is undisclosed. A utility interruption, UPS fault, cooling problem, access restriction or facility maintenance can affect customer service even when 365.hosting's own staff and routers are healthy.
The third is rack and hardware failure. “Own racks” concentrates useful control but also creates responsibility for power distribution, top-of-rack switching, hypervisors, drives and spares. A five-to-ten-day new-server setup window cannot be treated as a replacement objective. Customers need to know whether failed disks are mirrored, whether a failed host triggers automatic VM restart elsewhere, whether backup data is in a separate fault domain and how quickly a dedicated server can be rebuilt.
The fourth is operational support. Public copy promises round-the-clock help, while chat hours are narrower and ticket targets are unpublished. A severe incident can be prolonged when the hosting provider, upstream and facility operator each wait for another party's diagnosis. Named escalation paths and joint incident procedures are more valuable than a general support badge.
The fifth is billing and account control. Shared WebHOST1 infrastructure, third-party payment scripts and private billing panels can become service dependencies. A payment dispute, fraud hold, expired card or account compromise can remove management access even while the hardware runs. Public pages do not state a grace period, suspension sequence, emergency contact or export right.
The sixth is migration. The site advertises free migration and a 30-day refund for some services. That lowers initial switching cost, but it does not prove rapid exit. Large datasets, private configurations, dedicated IP reputation, DNS timing and application dependencies can make migration slower than server provisioning. No reviewed page promises portable VM images, bulk export bandwidth, retained snapshots after cancellation or assisted evacuation during a facility problem.
These are not allegations of failure. They are the dependency chain created by the public operating arrangement. The weak point is not necessarily one component; it is the handoff between components whose contracts and tested recovery behaviour are not disclosed.
Two sales countries do not yet make a recovery pair
The presence of both US and Dutch offers invites a common assumption: if one site fails, workloads can move to the other. The public pages do not make that promise. They sell locations independently. They do not describe active-active service, replicated storage, shared orchestration, common private networking, DNS failover or reserved standby capacity.
Cross-site recovery would also cross a legal and latency boundary. Moving data from the Netherlands to New Jersey can change the applicable jurisdiction, customer notice obligations, transfer mechanism and round-trip delay. A customer that selected the Netherlands for European processing cannot assume that US restoration is acceptable. The controlled topic of data sovereignty is relevant precisely because location is part of the product, not because the evidence proves a compliance breach.
Even within the Netherlands, Kolo's four listed facilities cannot be counted as 365.hosting redundancy. Kolo advertises multi-site resilience options, but 365.hosting does not identify its facility or state that customer data is replicated to another one. A carrier-neutral hall creates options; it does not create a second contracted service automatically.
Likewise, MIRhosting's facilities in both countries do not prove that AS30344 has independent handoffs at both. The one-neighbour BGP view can cover multiple physical links to the same AS, or it can cover one. Public data do not distinguish them. A credible redundancy statement would name the sites, circuits and failure test while preserving legitimate security details.
Customers should therefore treat the country menu as a placement choice, not a recovery architecture. Those needing continuity across site loss must design and purchase it explicitly: application replication, separate credentials, independent DNS, backups outside the primary account, tested restoration, capacity reservations and a legal basis for the secondary location. The provider's public material does not show that these controls are included by default.
Who is exposed when the system fails
The home page's “20,000+ projects” claim implies a meaningful user base, but no independent breakdown connects that number to current AS30344 services. Reverse-DNS and hosted-domain observations confirm that the routed space carries internet-facing systems. They do not reveal whether those systems belong to small websites, agencies, software services, game servers, shops, internal corporate tools or infrastructure resellers.
The product language points to several affected groups. VPS customers can lose web applications, databases, VPNs and development environments when a host or route fails. Dedicated-server customers may face a longer hardware replacement because their environment is tied to a specific chassis. Domain and DNS customers can be affected at a control layer even if their content is hosted elsewhere. Resellers can amplify one upstream incident across many end clients who may never have heard of 365.hosting.
The customer impact also depends on address continuity. Moving a workload to another provider without retaining the same IP can disrupt allowlists, mail reputation, DNS caching, API integrations and security rules. The four /24s are therefore operational assets beyond their numerical size. Yet no public portability policy says whether a customer can bring an address, announce its own prefix, retain an IP during migration or obtain BGP service.
Data loss and unavailability are separate outcomes. A route failure can make intact data unreachable. A storage failure can destroy data while the network remains healthy. A billing lock can block control while public services continue temporarily. Recovery planning should identify which state is being protected: packet reachability, VM power, data durability, management access or application correctness.
The limited disclosure means customers must supply much of this resilience themselves. Off-provider backups, documented rebuild steps, secondary DNS, independent domain credentials, monitoring from more than one network and rehearsed migration reduce dependence on claims that cannot be externally verified. The need is greatest for customers whose own users assume that buying a “cloud” service includes invisible failover.
What the evidence supports, and what it does not
The evidence supports calling 365.hosting an operating hosting provider associated with an active US-registered autonomous system. Its domain resolves inside AS30344. Its IPv4 prefixes are being announced, the newest block entered routing immediately after assignment, reverse DNS shows hosting use, and product pages accept a detailed commercial vocabulary of processors, disks, channels and locations. This is materially stronger than a directory card built only from a name.
It also supports a specific concentration finding. At the July 15 snapshot, all observed AS30344 routes had one visible AS neighbour, MIRhosting AS52000. Four IPv4 origins were RPKI-valid; the IPv6 origin was unknown rather than invalid. The route evidence says nothing about hidden backup links, but no public proof of a second transit or tested failover was found.
The physical evidence supports Secaucus at city and facility-history level for the US offer, with a correction: H5, not vXchnge, now presents the 200B Meadowlands Parkway facility. For the Dutch offer, it supports a legacy Serverius product label and a current Kolo platform with four Dutch sites, without identifying Dronten, Meppel, Apeldoorn or Amsterdam as the 365.hosting location. It does not support Wyoming as a server location.
The capacity evidence supports current plan specifications and a five-to-ten-day dedicated provisioning window. It does not disclose installed or available server counts, rack occupancy, aggregate bandwidth, power, spare inventory, sold percentage or usable capacity after a failure. The 99.9 percent and customer/project metrics remain marketing claims without published measurement detail.
The corporate evidence supports a public affiliation among 365.hosting, 365.partners and WebHOST1 through shared contacts, domains, page infrastructure and registry records. It does not make every AS198178 resource part of AS30344 or prove that another group network is a standby. Nor does it disclose which entity owes each customer the complete service.
This is a medium-strength network finding and a weak-to-medium infrastructure disclosure. The downgrade is deliberate. The route origin and storefront are real; the exact operating and recovery boundaries remain too opaque for a stronger resilience conclusion.
The next proof should be operational, not promotional
The easiest correction is editorial: update the Secaucus facility name and identify H5 as the current operator, while explaining the role of 365.hosting and MIRhosting. A customer should not have to reconcile a 2026 launch post with H5's current site identity and acquisition sources that date the transaction to either 2021 or 2022. The Netherlands page should update the Serverius label for the Kolo transition and identify the relevant Kolo facility code and city.
The next step is a service-to-infrastructure matrix. For each US and Dutch product family, 365.hosting could state the facility operator, contracting entity, route origin, upstreams, backup location, support channel and applicable SLA. It need not reveal rack numbers or sensitive topology. It should make clear whether the customer buys a VM, dedicated chassis or managed service and which components are shared.
For network resilience, a dated failover note would settle much of the uncertainty: the number of AS30344 transit relationships, whether they terminate in separate facilities, whether IPv4 and IPv6 have the same protection, and the last successful route-withdrawal test. The single-neighbour view would then be interpretable as collector limitation, intentional design or genuine concentration.
For capacity, the useful metrics are not the total address count or facility square footage. They are installed hosts, powered racks, available configurations, spare hardware, aggregate committed bandwidth and replacement objectives. Status should distinguish design, installed, powered, in service, sold, reserved and available capacity. A provider can disclose ranges or percentages when exact numbers are commercially sensitive.
For recovery, customers need restore-point and restore-time objectives, backup fault domains, image-export formats and a documented path out of the platform. Cross-border recovery should be opt-in and legally explicit. A 30-day refund is a commercial assurance; it is not a disaster-recovery design.
Finally, the public status record should carry incidents and maintenance in consistent English, with affected location, service, start and end time, impact, cause and remediation. Serverius already demonstrates the value of this practice in its own NOC notices. Extending that clarity to 365.hosting's customer layer would do more for confidence than another generic uptime badge.
Until those proofs appear, the most accurate reading remains narrow. 365.hosting has put real address space into service, including a newly assigned /24. It sells identifiable hardware in two countries and appears embedded in a wider hosting group. But in the reviewed July 15 view the newest route still met the public internet through one visible upstream, the US facility label was at least four years behind its operator record, and the Dutch label did not resolve to one of Kolo's four sites. Neither the sales catalogue nor the route table proves how much capacity survives the failure of a rack, site, contract or control plane.