Summary
- ServerHosh presents a broad catalogue of shared hosting, VPS and dedicated servers from an Indian commercial base, with locations advertised in Seattle, Philadelphia, Phoenix and London. The clearest independently current network evidence is narrower: AS136175 originates one IPv4 /24 through Wowrack and has a 1 Gbps connection at the Seattle Internet Exchange.
- The company says it owns hardware and networking gear, operates direct transit, and uses private suites in Wowrack's Seattle facility and Iron Mountain LON-1. Public records establish the facilities and some ServerHosh-labelled address space, but do not disclose its rack count, contracted power, usable failover capacity, spare inventory or precise London room.
- A 1 Gbps or 10 Gbps server-port label is not dedicated end-to-end capacity. ServerHosh's own fair-use language permits port restriction for sustained high-bandwidth workloads, while the current global route for its own ASN exposes only one observed upstream and no originated IPv6 space.
- Recovery is also divided by product. Shared hosting advertises daily two-tier backup and cPanel migration, while the general terms call VPS and dedicated servers unmanaged and impose short deletion windows after non-payment. Customers therefore need an independent restore, export and billing-continuity plan rather than treating a low monthly price as a complete resilience product.
A cloud storefront with a physical supply chain
ServerHosh makes infrastructure look like a list of small monthly choices. Its current home page promotes shared hosting from $1.99, virtual machines in the United States and Britain, and dedicated servers in France, Seattle and London. The catalogue stretches from a one-gigabyte web-hosting account to a dedicated machine with 128 gigabytes of memory. A customer can select cores, memory, disk and a port speed without ever seeing a rack, a breaker, a fibre tray or the person who will replace a failed drive.
That separation is normal in hosting. It is also where the risk sits. ServerHosh is not merely selling CPU time. It is assembling a service from physical servers, virtualisation software, IP addresses, upstream networks, a billing system and support labour. In Seattle and London, it also depends on organisations that control the buildings, power systems, cooling plant, security desks and remote-hands access. The capacity visible to a buyer is the final slice of a longer chain.
The company describes itself as an Indian hosting provider operating since 2012. Its about page names Anirban Ghosh and Srabanti Paul as owners and lists operational and support roles. A separate corporate record reports that Serverhosh Internet Service Private Limited was incorporated in West Bengal in October 2020, with Ghosh and Paul as directors. These dates can coexist: a trading brand or unincorporated operation can precede a private limited company. They should not be collapsed into a claim that the present company has had the same assets, contracts or operating structure since 2012.
The customer-facing office is also separate from the machines. ServerHosh's contact page gives a Kolkata address and an Indian telephone number. It advertises support around the clock, while sales and billing are listed as operating Monday to Saturday. The machines are promoted as being thousands of kilometres away. That is a distributed service arrangement: commercial administration in India, hardware and network capacity in foreign facilities, and customer demand that may come from anywhere.
This arrangement can be economical. A small provider does not need to build a data centre to rent a private cage, buy dedicated servers, lease IP transit and place customers on virtual machines. It can combine lower overhead with direct support and narrow product choices. But the same arrangement creates several boundaries that a buyer must map. Who owns the server? Who holds the facility contract? Who is authorised to enter the room? Who announces the address space? Which party replaces a disk at 03:00 local time? Which contract controls a refund, a suspension, a maintenance window or a data export?
ServerHosh's public materials answer parts of those questions and leave others open. The useful conclusion is not that the service is imaginary or that every claim should be accepted. It is that operation is visible at some layers and opaque at others. The network has a current public trace. The product catalogue is active. Named third-party facilities exist. Yet the amount of sellable capacity, the path from a ticket to a repaired server, and the ability to restore customer data after a common failure are not published in a form a customer can test.
The strongest current evidence is one Seattle route
ServerHosh has its own autonomous system, AS136175. The APNIC registration identifies Serverhosh Internet Service, a Kolkata address and Anirban Ghosh as the administrative and technical contact. The record assigns the autonomous system a Netherlands country code while the associated organisation record says India. Country fields in internet registries are administrative labels, not a reliable map of where every server or router is installed.
The live routing picture is compact. Hurricane Electric's AS136175 profile showed one originated IPv4 prefix, 209.90.232.0/24, one observed IPv4 neighbour, Wowrack's AS23033, and no originated IPv6 prefix on 10 July 2026. RIPE's routing-status measurement independently showed the same 256-address IPv4 space, no IPv6 space and one observed neighbour. Its announced-prefix history showed that /24 continuously visible during the preceding two-week query window.
That is positive operating evidence. A current route does not appear merely because a website says a service exists. It requires address administration, a router policy and an upstream willing to propagate the prefix. IPinfo also reports recently pingable address space in the /24, including a response measured from Seattle. The observations support an active Seattle network footprint associated with ServerHosh.
The Seattle Internet Exchange adds a second form of evidence. Its current entity table lists ServerHosh at IPv4 address 206.81.81.217 and IPv6 address 2001:504:16::2:13ef, connected at 1 Gbps on the Wowrack switch. The entry marks the connection and voting membership as current. PeeringDB's ServerHosh network record reports the same addresses, an open peering policy and a global scope.
The exchange entry has to be read carefully. It does not show ServerHosh delivering routes to the SIX route servers, and it does not turn a 1 Gbps exchange port into a second transit provider. Peering can improve reach to willing members, but a public exchange port and a full-internet upstream perform different jobs. A customer workload still needs a complete route to networks that do not peer with ServerHosh. The one globally observed neighbour remains Wowrack.
There is also a sharp scope difference between the current observations and ServerHosh's network page. The company says its Seattle service has 110 Gbit/s of current blended capacity, a 100 Gbps Hurricane Electric transit connection, a 10 Gbps Wowrack connection, redundant switches and access to SIX. Those figures may describe facility connectivity, historical design, capacity available to a supplier, or links not used to announce AS136175's one visible prefix. They are not corroborated by the public route for that ASN or the 1 Gbps exchange entry.
This does not prove that the larger links are absent. A hosting provider can use provider-assigned addresses announced under a supplier's ASN, private VLANs, protected transit or capacity that collectors cannot attribute to its own autonomous system. The current evidence establishes less: ServerHosh controls one visible IPv4 route through Wowrack and one exchange connection in Seattle. A current circuit inventory, router configuration summary and traffic graph separated by location would be needed to validate the larger capacity statement.
IPv6 illustrates the same distinction. SIX and PeeringDB assign ServerHosh an IPv6 exchange address, so an IPv6-capable interface exists on the exchange fabric. Yet the company originates no IPv6 customer prefix in the global table. An exchange LAN address is infrastructure for peering; it is not a routed allocation that a VPS customer can necessarily use. A buyer requiring dual-stack service should therefore test a provisioned virtual machine and confirm an IPv6 prefix, default route, reverse DNS and failover behaviour, not rely on the exchange record alone.
The Seattle facility belongs to the landlord's operating domain
ServerHosh says it has a private suite with Wowrack in Seattle. Wowrack's own SEA1 data sheet describes an 18,000-square-foot, 450-rack facility at 12201 Tukwila International Boulevard with 3 MW of power capacity, N+1 cooling, UPS and generator systems, remote hands, carrier-neutral connectivity and on-net SIX access. Wowrack's company history says it expanded to a 3 MW, 18,000-square-foot Seattle facility in 2014.
The overlap between those figures and ServerHosh's own description is striking. Both cite 18,000 square feet, 3 MW, cooling plant redundancy, high rack density, SIX access and the same general Seattle operating context. This supports the interpretation that ServerHosh is describing the capabilities of the Wowrack facility in which it rents space, not a building it owns. That is consistent with its statement that it colocates in Seattle and with the public BGP relationship to Wowrack.
Facility capability still matters to a tenant. If the site's generators, chillers or access systems fail, the ServerHosh racks are affected. But a building-wide specification cannot be carried through automatically to every customer product. A 3 MW plant says nothing about the number of kilowatts contracted to ServerHosh, the loading of its power strips, whether its servers have dual power supplies connected to separate paths, or how much headroom remains after a component failure.
The physical address also requires care. A commercial directory associates ServerHosh with an older-looking Seattle address, while Wowrack's current documents place SEA1 at 12201 Tukwila International Boulevard. The facility operator's current data sheet is stronger evidence for present location. It still does not identify ServerHosh's cage, suite, rack count or cabinet power. A customer seeking physical assurance should ask for the current service address in the order, the facility operator, suite or cage entitlement, access procedure and the point at which ServerHosh's responsibility begins.
Wowrack's facility rules show why the boundary has operational consequences. Deliveries must be arranged through a Wowrack support ticket, and the operator can take remedial action when unsafe or unacceptable conditions are not corrected. This is ordinary colocation governance, but it means a ServerHosh hardware replacement can depend on supplier procedures, shipping acceptance and remote-hands coordination before its own staff can complete the repair.
The ownership boundary therefore has at least four layers. Wowrack or the property owner manages the site plant and access regime. Wowrack provides network transit visible in BGP. ServerHosh says it owns hardware and network gear within its footprint. The customer controls the operating system and application for unmanaged products. A recovery plan that names only ServerHosh misses the parties controlling the room, route and workload.
London is visible, but the exact room is not
ServerHosh's British story is more complex. The company says its private suite is in Iron Mountain LON-1. Iron Mountain's official LON-1 profile describes a large Slough facility with six data halls, 17,000 square metres and 8.7 MW of power, plus individual cabinets, cages, private suites and round-the-clock smart hands. A separate Iron Mountain location overview lists LON-1 at 724-729 Dundee Road, with N+1 chillers, generators and UPS systems.
Those records establish LON-1 and its broad facility capabilities. They do not establish which room, rack or power path ServerHosh occupies. ServerHosh is not listed with a London interconnection facility in its PeeringDB record, and AS136175 does not expose a London route. Neither fact disproves a private suite. Private customer deployments often do not appear in public facility databases, and a provider can use address space announced by another network.
There is a more specific London signal. The hostname ServerHosh publishes for its London looking glass resolves into 41.216.187.0/24. The registration and routing profile for that prefix labels it ServerHosh Internet Service and places it under PebbleHost customer ASN AS201002 in the United Kingdom. BGP.tools also shows the ServerHosh-labelled /24 under PebbleHost. This supports a current British address-space relationship but does not tie the route to Iron Mountain LON-1.
The distinction matters because data-centre location and network origin are different facts. A ServerHosh server could sit at LON-1 while its traffic is carried by PebbleHost. It could also be hosted in another British facility using the same prefix. The DNS hostname, prefix registration and low-latency London observations establish a British network presence at a useful level, but a buyer requiring Slough residency needs contractual confirmation of the physical site and the list of sub-providers.
ServerHosh's current UK dedicated-server page explicitly names Iron Mountain LON-1 and advertises Ryzen systems with 1 Gbps unmetered connections. Yet the linked order catalogue showed zero units available for each displayed UK dedicated-server configuration when checked. Zero stock does not prove the location is inactive. It does show why catalogue design and installed capacity must be separated. A page can continue advertising a product whose immediately provisionable inventory is exhausted or awaiting custom assembly.
The London VPS catalogue makes a broader promise. ServerHosh advertises 10 Gbps virtual machines with unmetered bandwidth, DDoS protection and 99.99% network uptime. The page says the physical host has a redundant 10 Gbps full-duplex port and that ServerHosh owns its hardware and networking gear. It does not state how many VPS instances share that host, whether both redundant ports terminate on independent switches, the fair-use threshold, or the measured throughput available during an attack or upstream failure.
This is not a semantic objection. A customer buying a virtual machine cannot consume more physical capacity than the host, switch and uplink can deliver. If twenty guests share one 10 Gbps host port, their advertised interfaces may all be 10 Gbps while simultaneous usable throughput is much lower. If a second port is a standby on the same switch stack, it protects a cable or interface but not the switch, transit carrier or facility. The missing number is not port speed; it is committed and tested service capacity under contention and failure.
Installed capacity is not the same as capacity for sale
ServerHosh's product pages reveal a wide mix of hardware generations and commercial assumptions. The NVMe shared-hosting page advertises plans on an Intel E3-1270v6 platform, from one gigabyte to 70 gigabytes of storage, with cPanel, CloudLinux, LiteSpeed and a 1 Gbps server connection. The storage VPS page says each physical server has four 4 TB SATA drives in RAID 10 and sells virtual allocations of 500 GB to 4 TB. The United States dedicated-server page lists older Xeon E3 and dual-Xeon machines in Seattle alongside newer Ryzen and Xeon choices in Philadelphia and planned stock in Phoenix.
There is nothing inherently wrong with older hardware. A paid-off server can make a low-cost hosting plan viable, and mature platforms can be stable when maintained. Age changes the operating equation. Replacement motherboards, compatible memory, RAID controllers and enterprise drives may be harder to source quickly. Power consumption per unit of work is often higher. Firmware support may be limited. The right question is not whether every machine is new, but whether the provider holds tested spares and can restore the workload within a stated period.
The USA dedicated-server catalogue exposes this inventory effect. Some Seattle systems are marked out of stock while others remain orderable; Phoenix configurations are marked soon. The page says most servers are custom configured and gives a usual delivery target within 48 hours, with up to three business days. That delay is evidence that a product card is not necessarily an installed, powered and ready machine. Provisioning may require assembly, testing, allocation or a supplier handoff.
Virtual capacity adds another layer. A VPS plan allocates virtual cores and memory, but public pages do not state the number of guests per host, CPU contention policy, memory overcommit, storage latency target or reserve host ratio. A provider can sell more nominal virtual cores than physical cores because customers rarely peak together. That is the economic engine of affordable VPS hosting. It becomes a failure issue when too many guests need capacity at once or when one host fails and remaining hosts lack room to absorb them.
Storage has similar arithmetic. Four 4 TB drives in RAID 10 provide roughly half the raw capacity before formatting and reserve space, not 16 TB of sellable protected storage. If a provider assigns multiple 4 TB virtual disks, it may depend on thin provisioning or on customers not using their full allocations at the same time. The page does not disclose the provisioning method. RAID 10 can tolerate certain drive failures, but rebuilding consumes I/O and a second failure in the wrong mirror can still lose the array. Capacity reserved for rebuilds and migrations is part of usable service capacity even though it produces no invoice.
Bandwidth labels are especially easy to overread. ServerHosh repeatedly uses "unmetered" beside 1 Gbps and 10 Gbps ports. Its general terms define unmetered service as subject to fair use, prohibit several continuous high-bandwidth applications and permit port-speed restriction when use falls outside the stated pattern. That makes unmetered a billing description, not a guarantee of sustained line-rate transfer.
A customer should therefore ask for four separate capacity figures: the interface speed presented to the server; any monthly transfer allowance or fair-use threshold; the committed rate during ordinary contention; and the minimum expected rate after a link, switch or host failure. Only the first is prominent in the catalogue. Without the other three, a 10 Gbps label describes a maximum local interface condition, not the throughput available to restore terabytes of data during an incident.
Power and cooling remain inherited promises
The two named facility operators publish credible engineering descriptions. Wowrack says Seattle SEA1 has 3 MW of power, 2N or N+1 UPS arrangements, generator backup, N+1 cooling and high-density support. Iron Mountain describes N+1 plant at LON-1. These are meaningful site attributes. ServerHosh's racks still depend on how its own equipment is connected within those sites.
A dual-corded server can receive two power paths. A single-corded low-cost server connected to one rack power strip cannot. Two rack strips can still share an upstream panel. A suite can be limited to a contracted kilowatt envelope even while the building has megawatts of installed capacity. Once a tenant reaches that envelope, it may have empty rack units but no power available for another server.
ServerHosh does not publish its contracted power, present rack loading, power-path map or percentage of dual-corded equipment. It also does not state whether its network switches, storage and out-of-band management follow the same redundancy pattern. A facility can meet its own design while a tenant creates a single point of failure inside the cage.
Cooling follows the load. The building operator may maintain N+1 chillers, but the tenant controls blanking panels, airflow, cable obstruction, rack density and how quickly new equipment is added. A high-density rack can develop a local hot spot while the room remains within its average target. A useful customer assurance would report inlet temperature at the rack, alarm thresholds, response ownership and the time needed to reduce load or move guests after cooling loss.
Power remains the most common cause of serious and severe data-centre outages in Uptime Intelligence's 2025 outage analysis. The report also warns that outage data is incomplete and that staff procedure failures matter. That is the correct level of inference here. It does not show that ServerHosh or either facility has suffered a particular power event. It shows why an unqualified uptime percentage is weaker than a tested path through utility loss, generator start, UPS operation, rack distribution and server restart.
Maintenance creates a more ordinary test than disaster. Generators need load tests. UPS modules need service. Switches need software changes. Disks need replacement. A resilient provider should be able to isolate one component without stopping the hosted workload, or explain the planned interruption if it cannot. ServerHosh does not publish a maintenance calendar, notification period, maintenance exclusion in its uptime claim or a history of completed failover tests.
The customer impact varies by product. A shared-hosting user may lose a website, email and database together because they share one server. A VPS user may retain an intact virtual disk but lose access when the host or upstream fails. A dedicated-server user may have no alternate machine at all. The facility's redundant plant reduces common risk, but only application replication to a genuinely separate failure domain can protect against the loss of the rack, suite, provider account or site.
Transit diversity is narrower than the location list
ServerHosh markets multiple cities, which can sound like network diversity. A location list is not a failover design. Seattle, Philadelphia, Phoenix and London products may be ordered separately, use different suppliers and have no automatic relationship to one another. A customer with one VPS in one city has one workload location regardless of how many other cities appear in the menu.
For ServerHosh's own ASN, the visible internet path is single-homed through Wowrack. The SIX connection provides a separate exchange attachment but does not appear to originate the company's one customer prefix through the exchange route servers. If the Wowrack transit session, internal handoff or ServerHosh router fails, the /24 can be withdrawn even if the building and servers remain powered.
The company network page names Hurricane Electric as a 100 Gbps main transit provider, but public collectors did not show AS6939 adjacent to AS136175 on 10 July 2026. Several explanations are possible: the link may serve provider-assigned addresses, sit behind Wowrack, be inactive, or be a facility capability described as tenant capacity. The public record cannot select among them. A current BGP summary showing established upstream sessions and which prefixes each receives would resolve the question.
There is also a scale mismatch between one visible 1 Gbps SIX port and product pages offering multiple 1 Gbps or 10 Gbps servers. The exchange port is not the only network capacity in the facility, so the catalogue is not mathematically impossible. It does mean the exchange cannot carry every customer's full advertised interface rate simultaneously. The same applies to any 10 Gbps host connection shared among virtual machines.
DDoS protection introduces another dependency. Product pages advertise protected service, and the London order catalogue refers to a 600 Gbps standard protection figure on some systems. That number may describe a mitigation platform's aggregate capacity rather than traffic deliverable to a single server. Effective protection also depends on detection, scrubbing policy, clean-path capacity, attack type, null-routing thresholds and customer communication. None is defined publicly.
The practical redundancy test has three parts. First, can the prefix remain globally reachable after one upstream session is disabled? Second, can the customer receive enough clean traffic after mitigation to keep the application useful? Third, can DNS, control-panel and ticket systems still be reached during the same failure? Passing only the first leaves the service operational on paper but unusable to the customer.
Hardware failure becomes a stock and access problem
Physical servers fail in specific ways. Drives accumulate errors. Fans seize. Power supplies trip. Memory develops faults. Motherboards and RAID controllers stop responding. The recovery time depends less on the phrase "reliable hardware" than on whether the exact spare is nearby, tested and accessible.
ServerHosh says it owns its hardware and networking gear. That can be an advantage because the company is not waiting for a retail cloud to expose a replacement option. Ownership also places inventory risk on a relatively small provider. The public catalogue does not show spare counts, reserve hosts, drive endurance, warranty coverage or the age distribution of installed equipment.
In Seattle, a repair may require ServerHosh to diagnose the fault remotely, open the correct Wowrack request, identify the cabinet, authorise work and provide or ship the part. Wowrack advertises 24-hour remote hands, but the scope, response time and cost in ServerHosh's contract are not public. In London, Iron Mountain advertises a target to acknowledge most smart-hands requests within 30 minutes. Acknowledgement is not restoration; the technician still needs an approved method and a replacement component.
Custom-configured dedicated servers make the inventory issue visible before an outage. ServerHosh gives a one-to-three-business-day delivery range and marks several configurations unavailable. A replacement during failure may not follow the sales delivery window, especially for an older Xeon platform or a customer-specific disk layout. A useful commitment would specify the repair objective by component, the parts held on site and the fallback if an exact replacement cannot be found.
VPS recovery can be faster if the provider has shared storage or replicated images that can boot on another host. ServerHosh does not describe such a cluster architecture. KVM virtualisation, advertised on several pages, isolates guests and can support migration, but KVM alone does not replicate a disk or reserve destination capacity. If the virtual disk exists only on drives inside the failed host, another hypervisor cannot recover it until storage is repaired or restored.
The repair window also interacts with security. A rushed replacement needs correct firmware, drive sanitisation, customer isolation and configuration control. A spare that has never been tested may lengthen the incident. A failed drive removed from a customer's system still holds data. Public terms do not specify media-retention, destruction or customer options for failed drives.
Customers can reduce this risk by treating a virtual or dedicated server as replaceable. Keep machine configuration outside the host, automate rebuilds, maintain current software images and test application restoration onto a different provider or location. That shifts recovery from waiting for a particular motherboard toward launching known-good capacity elsewhere.
Backup claims divide sharply by product
ServerHosh's home page says it performs daily backups for hosting. The NVMe shared-hosting page is more specific, listing daily two-tier backup and RAID 1 storage. Those promises appear to apply to shared hosting. The general terms say all VPS and dedicated servers are unmanaged and receive only basic support. They do not promise provider-managed backup for those products.
That distinction is easy to miss because "free backup" appears beside some VPS promotions. A buyer needs to know whether backup means a host snapshot, a copy in the same rack, a copy in another facility, or a service the customer must configure. It also needs retention length, frequency, encryption, restore cost and the last successful restore test. None of those details is published across the product set.
RAID is not a substitute for backup. Mirrored or striped redundancy can keep a volume running after a drive failure, but it also reproduces accidental deletion, corruption and ransomware. If the whole server, controller or rack is lost, the array is lost with it. A host snapshot can fail for the same reason if it resides on the same storage pool.
CISA's ransomware guidance recommends offline, encrypted backups and regular integrity and restoration tests. NIST's contingency-planning guide similarly treats alternate storage, alternate processing, telecommunications and backup as related parts of recovery. These are general benchmarks, not evidence that ServerHosh follows or fails them.
For ServerHosh, the decisive evidence would be a product-specific backup schedule and a restore result. A shared-hosting report could state when each tier completed, where the second copy resides and how long a full account restoration took. A VPS option could define snapshots separately from independent backups. A dedicated-server customer should assume no provider copy unless the order expressly adds one.
The public uptime page does not close this gap. It presents a seven-day calendar and date-range calculator but exposes no named services, incident history, location breakdown or restoration metrics in the accessible view. An uptime monitor can show that an endpoint answered; it cannot show whether backups are current or whether a corrupted server can be rebuilt.
Customer reviews provide only weak signals. ServerHosh's claimed Trustpilot profile contains positive accounts of stable service and quick help, alongside complaints about downtime, support communication and data loss. There were 64 reviews and no reviews in the preceding 12 months when checked. Reviews are self-selected, cover different products and periods, and cannot establish a current failure rate. They do identify the questions buyers should test: response time, bandwidth interpretation and restore responsibility.
Billing can stop a healthy server faster than hardware
Not every outage begins in a data hall. ServerHosh's terms say a dedicated server may be permanently terminated 24 hours after an unpaid invoice, a VPS deleted after 72 hours, and shared or reseller hosting terminated after five days. Those windows are short compared with many business recovery processes. An expired payment card, missed email or disputed invoice can become a data-loss event while the physical machine remains healthy.
The risk is amplified by the division of support hours. Technical support is advertised continuously, but billing is listed Monday to Saturday. A suspension late in the week may require commercial authority that a technical responder does not hold. Public materials do not state an escalation path for a billing error threatening imminent deletion.
Refund language is inconsistent across pages. The general refund policy gives monthly shared hosting a 15-day guarantee, excludes dedicated servers, restricts several other cases and says policies may change. The NVMe page describes a 15-day refund followed by a possible partial refund. The London VPS page offers a full refund within 48 hours and a partial refund later. The UK dedicated page says a refund is available if delivery does not occur within 48 hours. A buyer cannot safely combine the most favourable sentence from each page.
The controlling commercial terms should be attached to the specific order. They should state delivery, cancellation, service credit, suspension notice, deletion timing and the handling of disputed payments. For an important workload, the customer should also keep more than one authorised billing contact, monitor invoice delivery outside the hosted domain and avoid storing the only copy of billing email on the service that could be suspended.
This is a hosting-economics issue, not mere administration. Low prices depend on standardisation, automation and strict control of abuse and non-payment. ServerHosh manually reviews orders, limits high-bandwidth uses and can terminate prohibited activity. Those policies protect scarce IP reputation, support time and transit capacity. They also create a need for accurate detection and a fair escalation process because an incorrect abuse or billing decision can remove a customer's only server.
The company has distinct support, sales, billing and abuse addresses, which is better than a single generic mailbox. It does not publish severity levels, response targets, named incident roles, phone escalation for existing customers or a post-incident reporting practice. Round-the-clock availability therefore describes the channel, not a guaranteed time to diagnosis or repair.
Migration is possible, but portability is conditional
ServerHosh advertises discounts for customers moving from another provider. Its NVMe hosting page says free migration is available only when the previous host uses cPanel. That is a concrete and sensible boundary: cPanel can package accounts, databases, mailboxes and settings in a format another cPanel server can restore. It also means the migration offer is not universal.
A WordPress site can often move with files and a database. A VPS may contain system users, firewall rules, licensed software, scheduled jobs, private networking and a large disk. A dedicated server may use a RAID layout or operating system that cannot be copied directly to different hardware. ServerHosh's public pages do not define how these workloads are exported or whether staff will help after the initial move.
IP addresses are another portability limit. A customer normally cannot take a provider-assigned address to a new host. Moving from ServerHosh's Seattle space or a supplier-announced London range may require renumbering, DNS changes, new reverse DNS and updates to allowlists. Email reputation tied to an address does not transfer automatically. A move made during an outage can therefore take longer than copying data.
Control panels reduce routine administration but can create dependencies of their own. ServerHosh uses cPanel for shared hosting and advertises virtual-machine panels for OS installation, reboot and console access. A customer should export data in ordinary formats and retain credentials outside the provider account. The management portal, billing system and hosted machine should not form one authentication failure domain.
NIST describes contingency planning as a combination of technical measures, procedures and alternate processing locations, not simply a backup file. For a ServerHosh customer, a realistic portability test would provision a clean machine elsewhere, restore the application, rotate secrets, change DNS and measure the time until users can connect. The test should include data created after the last backup and dependencies such as mail, certificates and payment callbacks.
Multi-site recovery is not established by ordering two ServerHosh locations unless their dependencies are mapped. Seattle clearly depends on Wowrack for the observed route. London address space visible through the published hostname depends on PebbleHost's routing. That is promising supplier diversity, but the customer still needs to confirm that accounts, control planes, backups and billing are not shared in a way that lets one commercial or security incident disable both.
The best exit position is one that works without provider intervention. That means current data copies, configuration records, domain control, independent monitoring, a tested destination and enough bandwidth to move within the required recovery time. A free migration offer can lower the cost of entering; only a tested export lowers the cost of leaving.
Data location needs a contract, not a city label
ServerHosh's service area is global, but its operating geography has several layers. The company and customer administration are in India. Public product pages place machines in the United States and United Kingdom, with additional offers mentioning France and the Netherlands. Network records show a ServerHosh-originated /24 in Seattle and a ServerHosh-labelled /24 routed through a British supplier. A customer's data may also pass through payment, support, monitoring and control-panel services outside the server city.
The company's privacy policy says it processes names, contact details, IP addresses, business information, payment details and communications, and that customer relationship data may be stored in WHMCS. It describes security and retention in broad terms. It does not identify hosting sub-processors, countries of processing, a fixed deletion schedule, international-transfer mechanisms or the facility used for each product.
This is separate from the contents of an unmanaged server. A hosting provider may act in different roles for billing records, support tickets and customer-hosted personal data. The UK Information Commissioner's Office explains in its controller and processor guidance that roles depend on who determines the purposes and means of processing, and that sub-processing changes responsibilities. Its international-transfer guidance specifically addresses a processor transferring information to a sub-processor abroad.
India's data-protection framework has also moved beyond a generic privacy statement. The Ministry of Electronics and Information Technology published the Digital Personal Data Protection Rules 2025, with an implementation timetable. The legal duties for any particular customer depend on the data, parties and effective provisions. The infrastructure lesson is simpler: a buyer cannot assess locality from the city in a product title alone.
A customer with residency or sovereignty requirements should ask ServerHosh for the exact physical country, facility operator, sub-providers, backup locations, support-access countries, logging locations and deletion process. It should also ask whether the assigned IP range is portable within the same country if the underlying supplier changes. The answer should become part of the service order and change-notification process.
The London evidence shows why. A page can name Iron Mountain LON-1 while a ServerHosh-labelled prefix and looking-glass host route through PebbleHost. Those facts are not contradictory, but they describe different control surfaces. Facility location answers where a server sits. Route origin answers who carries its address space. Support location answers who may access it. Backup location answers where another copy exists. Data sovereignty requires all four.
Six failures reveal the real service
The first failure is a rack or facility interruption. If ServerHosh's contracted power path, cooling zone or cabinet fails, the underlying building redundancy may limit the incident, but only dual-corded equipment and spare capacity can keep the workload live. Customers on a single host are affected until power returns, the host restarts or the workload moves. Evidence that would improve confidence includes a tenant-level power map, dual-feed coverage, last integrated test and a customer notification record.
The second is upstream loss. AS136175 currently has one observed global neighbour. SIX membership is useful but does not by itself supply a full alternative route. A transit session failure can remove the company's /24 while the servers continue running. A second independently routed upstream, tested prefix failover and current route-server participation would reduce this risk.
The third is hardware-stock failure. A drive can be replaced quickly if a compatible spare is in the same building and remote hands are authorised. It can take much longer if the part must be sourced, shipped, admitted and installed. Older dedicated-server generations increase the importance of stocked spares. The relevant measure is repair and workload-restoration time, not the CPU type in the sales table.
The fourth is support failure. A ticket channel may be open while diagnosis, supplier escalation or commercial approval waits. Customers need a severity path that reaches someone empowered to contact Wowrack, Iron Mountain or another network provider. Published targets for acknowledgement, diagnosis, workaround and restoration would make 24-hour support measurable.
The fifth is billing or policy failure. A valid server can be deleted under the published non-payment windows, and prohibited-use enforcement can suspend service. Multiple billing contacts, longer notice for established customers, an appeal route and an export grace period would prevent an administrative dispute from becoming irreversible data loss.
The sixth is migration failure. A customer may discover during an outage that its backup is local, its control-panel export is incomplete, its IP reputation cannot move and its DNS credentials are trapped in the same account. A successful restoration to another provider is stronger evidence of portability than a promise of free inbound migration.
These failures affect different groups. A personal-site owner may tolerate several hours and rebuild from a recent copy. A reseller may have dozens of downstream customers and no direct access to the facility operator. A business using an unmanaged VPS may be fully responsible for its application while still depending on ServerHosh for host recovery and routing. A dedicated-server customer may own the software stack but have no physical access to replace hardware.
What would materially improve confidence
ServerHosh already publishes more infrastructure detail than many budget hosts. It names facilities, transit providers, equipment classes, exchange membership, backup claims and product limits. The next improvement is not a larger uptime number. It is a smaller set of current, scoped facts.
For each location, the company could publish the facility operator and address, its role as owner or tenant, active rack count, contracted and available power, server and network-spare policy, upstream sessions, exchange ports, customer IPv4 and IPv6 availability, DDoS policy, maintenance notice and remote-hands escalation. Sensitive diagrams and customer details are unnecessary. Aggregate operating facts would be enough.
For each product class, it could separate interface speed from fair-use policy and committed throughput; define whether service is managed; specify backup frequency, location and retention; state recovery objectives; and attach one consistent refund, suspension and deletion policy to the order. A status page could name services and locations, retain incident history and report maintenance without exposing security information.
The strongest proof would be a routine exercise. Withdraw one transit path and show the alternate route. Restore a shared-hosting account from the second backup tier. Evacuate a VPS from a failed host. Replace a dedicated-server drive through remote hands. Rebuild a representative customer application in another location. Report the time, limitations and corrective actions.
Until that evidence is public, ServerHosh should be assessed as a small, active hosting provider with a real but concentrated network footprint, credible access to third-party data-centre capacity and substantial uncertainty around tenant-level redundancy. Its low prices and broad menu may suit workloads designed to be replaceable. They should not be confused with a managed multi-site recovery service.
The physical lesson is the most important. ServerHosh can package cores, storage and bandwidth into a convenient monthly product, but it cannot virtualise away a failed rack, a withdrawn route, an unavailable spare, a missed invoice or an untested restore. Customers buy resilience only when those dependencies are named, divided across independent failure domains and exercised before the repair window begins.