Summary
- Serverwala markets more than 50 data centres across six continents and colocation in dozens of Indian cities, yet its location pages describe partnerships and long-term agreements with other data-centre operators. The public evidence supports a hosting and network operator with a partner estate; it does not establish ownership of those buildings.
- AS149573 provides strong evidence of current network operation. A 12 July 2026 RIPE RIS snapshot showed 17 originated IPv4
/24prefixes, full visibility among 325 IPv4 collector peers, four visible commercial upstreams across the portfolio and no visible IPv6 route. - Portfolio-level carrier choice is not the same as resilience for an individual customer. In public route paths, each current prefix was dominated by one immediate upstream: eight by TeleIndia Networks, six by Primesoftex, two by CtrlS and one by Yotta Network Services.
- Fifteen current prefixes were RPKI-valid in the same check, but
151.242.51.0/24and193.151.181.0/24were invalid because their published route authorisations named AS834 rather than Serverwala's AS149573. That mismatch can affect reachability through networks that reject invalid routes. - The evidence grade is Medium for current network operation and Weak for facility-level resilience. Buyers need named sites, certified topology, utility and generator evidence, carrier path maps, tested failover results and contract terms tied to the exact rack or server location.
A Kolkata offer that points somewhere else
One page captures the central problem unusually well. Serverwala's Kolkata colocation offer says the company has five-to-ten-year agreements with data centres in India and promises redundant grids, uninterruptible power supplies, generators, cooling and 24-hour remote hands. Yet a specification table on that same Kolkata page quotes electricity and air conditioning for a location in Germany, prices remote hands in euros and lists euro-denominated subnet charges. The page may combine commercial modules intended for different markets. Whatever the explanation, it cannot be read as a clean engineering specification for one Kolkata facility.
That inconsistency matters more than a stray currency symbol. A customer choosing colocation is not buying the idea of Kolkata. It is buying a cabinet in a particular building, connected to particular switchboards, generators, chillers, fibre entrances and operating teams. When the sales page blends a city offer with another country's facility economics, the customer cannot tell which statements describe the place where its equipment will actually sit.
Serverwala's Noida page has the same broad structure. It offers plans from one rack unit to a full 40U cabinet, describes multiple sources of power, UPS systems, backup generators and multiple network links, and then explains that access comes through alliances with other data centres. The page does not name the building, utility connection, generator configuration, carrier entrances or facility operator behind each plan. It gives a purchasable product without exposing the underlying fault domains.
This is not proof that the service is unavailable. It is evidence that availability must be established at order level, not inferred from the location name. An intermediary can deliver excellent infrastructure through disciplined contracts and capable partners. It can also create a longer restoration chain: customer to Serverwala, Serverwala to the facility, facility to the utility or carrier, and then back again. The quality of that chain depends on rights, escalation times and tested cooperation that the location catalogue does not show.
The company boundary is narrower than the global map
The legal and commercial identity is reasonably clear at the Indian end. Serverwala's website identifies the national billing entity as Serverwala Cloud Datacenters Private Limited and gives the corporate identity number U72501RJ2020PTC069177. Public company information records the entity as incorporated in Jaipur on 18 June 2020. The company's contact page lists offices in Jaipur, Surat, Nashik and Mumbai, while its about page says the brand began in 2015 and has a Dubai branch.
Those dates can coexist: a brand or earlier operation may predate the present company. They should not be collapsed into a claim that this specific 2020 entity owned a global facility portfolio from 2015. The useful boundary for an Indian customer is the entity named on the invoice and contract. Serverwala's terms say Indian customers contract with the Indian private company while international customers use Serverwala InfraNet FZ-LLC in the United Arab Emirates. Later clauses on the same page still refer to another Serverwala corporate form, which makes a signed order form and an explicit precedence clause more important than the general website text.
The global map is much wider. The homepage advertises more than 50 data centres across six continents, more than 8,500 dedicated servers, 6,800 cloud servers, 1,500 GPU servers and 14,000 business customers. It offers deployment across many Indian cities and international markets. These figures are company claims. No public site-by-site inventory accompanies them with building names, operator names, commissioned megawatts, occupied racks, audit dates or certification identifiers.
Serverwala's own wording indicates the likely operating model. The Noida page refers to partnerships with data centres across India. The Kolkata page refers to long-term agreements and direct contracts with local vendors and technology companies. A United States colocation page similarly describes five-to-ten-year agreements with data-centre partners. The consistent reading is that Serverwala packages capacity, support and connectivity across a supplier network. That is a legitimate business model, but the words "our data centres" on a sales page should not be treated as a property register.
Ownership is not the only question. Operational authority is equally important. Who can approve emergency access? Who owns the UPS and generator maintenance contract? Who controls the edge router? Who can move a customer to another carrier during a cut? Who decides whether a failed disk, power supply or cross-connect is replaced at 2am? A reseller can hold some of those rights and delegate others. Buyers need the division written down for their site.
AS149573 is evidence of a real operating network
The public network record is more concrete than the facility catalogue. APNIC's RDAP record shows AS149573 as active, registered on 12 May 2022, with administrative and technical contacts tied to Serverwala and its Jaipur registered-office address. RIPEstat's AS overview names the holder as Serverwala Cloud Datacenters Private Limited and showed the autonomous system announced on 12 July 2026.
The RIPEstat routing-status view adds scale. It recorded 17 IPv4 prefixes containing 4,352 addresses and visibility from all 325 IPv4 RIS peers in the snapshot. The first observed Serverwala route was 103.183.157.0/24 in August 2022. The same view found no IPv6 announcement. Serverwala's public terms also say its servers do not normally include IPv6, subject to location-specific exceptions described on the page, so the routing and commercial statements broadly align.
Seventeen routed /24s are not trivial. They establish that Serverwala is not merely a company name attached to generic hosting pages. The network was visible globally, originated address space used across several locations and had multiple upstream relationships. IPinfo's AS149573 view identified responsive infrastructure in Mumbai, Bengaluru, Ahmedabad, Hyderabad and Kolkata and listed roughly 1,800 hosted domains across 100 addresses when captured. Geolocation is approximate, and a responding router is not proof of a rack address, but the spread supports an active multi-city Indian service surface.
The result still needs discipline. An autonomous system is a routing policy boundary, not a list of buildings. One ASN can announce equipment in partner facilities, carry leased address space, provide transit to another network or front services whose servers belong to customers. Conversely, a customer may receive addresses from a facility or upstream rather than from AS149573. The ASN proves network operation; it does not prove that Serverwala owns every rack, cooling plant or fibre route associated with the traffic.
The address portfolio also changes. The announced-prefix history showed two currently active blocks, 103.131.26.0/24 and 103.183.156.0/24, absent for part of the preceding two-week window before reappearing. Other blocks appeared only late in that period. A route collector's timeline cannot by itself distinguish maintenance, migration, policy change, measurement effects or customer impact. It does show why an annual screenshot is inadequate: reachability has to be watched continuously and correlated with service incidents.
Four upstreams do not give every server four exits
At ASN level, the carrier picture looks promising. The RIPEstat neighbour view observed Yotta Network Services, TeleIndia Networks, Primesoftex and CtrlS on the upstream side, plus Dynowave Technologies as a downstream. IPinfo independently listed the same four upstreams. These relationships spread Serverwala's routes across several Indian networks and reduce dependence on one supplier at portfolio level.
The prefix view is less redundant. Counting the dominant immediate upstream in public RIPE RIS paths for the 17 current prefixes, eight reached the wider internet primarily through TeleIndia Networks, six through Primesoftex, two through CtrlS and one through Yotta. The looking-glass route for 103.183.156.0/24, for example, overwhelmingly placed AS150609 immediately before AS149573. 103.131.24.0/24 was overwhelmingly behind AS17426, 151.243.12.0/24 behind AS18229, and 103.131.25.0/24 behind AS140641.
Some paths showed a small number of observations through a second neighbour. That may reflect a backup, a transition or collector-specific propagation. It is not enough to conclude that the remaining path can carry full customer load, that failover is automatic, or that the fibres are physically separate. The dominant pattern is one immediate upstream per prefix even though the portfolio as a whole has four.
This distinction is the core of carrier resilience. A company can truthfully say it works with multiple carriers while a particular rack has one cross-connect to one router, one local loop or one active upstream. It can also have two logical sessions that enter through the same duct, terminate on the same line card or depend on the same meet-me room. BGP diversity, carrier diversity, building-entry diversity and capacity diversity are separate properties.
Serverwala's hosted-bandwidth page promises multi-carrier access through a meet-me room, dynamic path selection, guaranteed bandwidth and a burstable option. Buyers should translate those statements into a prefix-specific design. Which two carriers serve the ordered location? Which routes are accepted from each? Are both sessions active? Do they terminate on separate routers and power feeds? What is the committed rate on the surviving link? Is the meet-me room itself a common dependency? The public route table cannot answer those questions.
There is also no public network profile for AS149573 in the PeeringDB API at the time checked. Absence from a voluntary database is not a fault. It means there is no operator-maintained public list there of exchange points, facilities, interconnection policy, traffic scale or network contacts that could corroborate the broad meet-me-room claims. A private interconnection inventory may exist, but a buyer has to request it.
Two route-authorisation conflicts deserve immediate attention
Route Origin Authorisation supplies a narrow but valuable control: it lets address holders state which autonomous system may originate a prefix. Networks performing Route Origin Validation can reject an announcement when the observed origin conflicts with the published authorisation. This does not stop every hijack or routing error, but it reduces one avoidable source of reachability failure.
Fifteen of Serverwala's 17 current prefixes were valid in the 12 July check. Two were not. RIPEstat's validation for 151.242.51.0/24 and 193.151.181.0/24 returned invalid_asn. In both cases, the covering authorisation named AS834, operated by IPXO, while the public route originated from Serverwala's AS149573.
That observation does not establish why the conflict exists. Address space can be leased, reassigned, migrated or temporarily announced under an arrangement that is not visible in BGP. The operational effect is clearer than the commercial explanation: a network that rejects invalid origins may drop those two Serverwala announcements even while other networks continue to accept them. Customers on the affected prefixes can therefore see reachability that varies by source network.
The remedy is measurable. The party controlling the route authorisation can publish a valid record for AS149573 or Serverwala can originate through the authorised ASN, depending on the intended arrangement. The correction should then be observed from multiple validators and upstream networks. Until that happens, these prefixes should not host a customer's only management address, backup endpoint or public service without an independent path.
RPKI validity is not a general resilience certificate. A valid route can still lead to an unpowered rack, a saturated link or a failed firewall. Here it matters because Serverwala has already completed the control correctly for most of its current portfolio. The two exceptions are visible, specific and fixable.
Power claims need a named electrical chain
The company's colocation pages use reassuring components: multiple power sources, UPS systems, backup generators and, on some pages, redundant power grids. Those are the right categories. They are not yet a design. The buyer needs to know how electricity travels from the utility connection to the exact A and B outlets feeding its equipment, and which elements can be removed without interrupting load.
"Multiple sources" can describe very different systems. Two utility feeds may come from one substation. Two transformers may share upstream switchgear. Two UPS modules may sit on one distribution path. A dual-corded server may have both cords connected to the same power distribution unit. A generator may have adequate nameplate power but limited public evidence fuel, cooling or starting reliability for a long outage. The useful evidence is a current single-line diagram, protective-device coordination, maintenance history, load-bank results and transfer-test records.
Serverwala's public pages do not provide those details by named Indian facility. They do not state generator runtime at measured critical load, on-site fuel volume, refuelling priority, UPS battery autonomy, utility feeder origin, rack power density or the maintenance state of each component. The company may hold all of that information privately through its partners. Without it, a promise of uninterrupted power remains a marketing claim attached to a city rather than an auditable capability attached to a building.
The word Tier requires the same precision. Some Serverwala pages describe Tier III colocation. Uptime Institute's Tier definitions define Tier III around concurrent maintainability: capacity components and distribution paths can be removed for planned work without shutting down the critical load. Tier Certification is site-specific and distinguishes design, constructed facility and operations. A generic statement that a service is Tier III does not identify which facility was certified, at what stage, to which version or whether the certificate remains current.
Generator endurance is particularly important where a provider depends on partner sites. Uptime Institute describes 12 hours of on-site fuel at the site's stated design load as a starting requirement for Tier-defined facilities, while also emphasizing fuel-system reliability. Twelve hours is not a guarantee that roads, suppliers and contracts will keep fuel arriving during a regional emergency. Serverwala should be able to state the tested runtime and replenishment plan for the ordered site, not merely that generators exist.
Cooling is capacity, not building decoration
Serverwala also promises climate-controlled or advanced cooling across its location pages. Again, the category is correct. Cooling determines how much IT load can remain usable during heat, maintenance and equipment failure. A room may have rack space available while lacking the chilled-water, refrigerant, airflow or electrical headroom needed for another high-density deployment.
ASHRAE's data-centre guidance links prolonged operation outside recommended environmental ranges to equipment reliability and longevity. That makes temperature control an operating record, not a photograph of cooling equipment. Buyers need inlet-temperature and humidity histories, alarm thresholds, sensor placement, cooling redundancy, maintenance isolation and the behaviour of the room after one cooling unit or pump fails.
GPU servers sharpen this issue. Serverwala advertises 1,500 GPU servers, but the public location pages do not break out rack density, cooling type, derated capacity during hot weather or whether every marketed site can host the same hardware. A conventional low-density rack and a dense accelerator rack can consume radically different power and cooling capacity. Counting servers without stating watts, thermal design and failover headroom does not reveal how many can stay online during a cooling fault.
Fire and water are parallel concerns. A buyer should see detection and suppression type, zoning, battery-room protection, leak detection, flood level, drainage, fire-department access and post-discharge recovery procedures. A suppression system may protect life and limit spread while still taking a room offline. A water leak may spare one rack but disable shared power distribution beneath it. Serverwala's pages promise security and monitoring but do not identify these site-specific controls.
Installed, sellable and recoverable capacity are different numbers
The homepage's server counts and location counts describe commercial scale, but they do not answer the capacity question that matters during failure. Installed capacity is equipment and space that exists. Sellable capacity is what the provider is willing to contract. Usable capacity is what can run within power, cooling and network limits today. Recoverable capacity is what remains or can be restored after a component, carrier or site is lost.
Serverwala's Noida plan illustrates the unit mismatch. It sells rack units, monthly data transfer, a 100 Mbps connection, a power allowance and a small address allocation. A full 40U plan is not 40U of unconstrained compute. The practical limit may be three kilovolt-amperes of power, the thermal envelope, the port commit or the available address space. A customer filling the rack with high-draw equipment could exhaust power long before space.
The same principle applies to the network. Seventeen /24 announcements represent 4,352 addresses, not 4,352 independent servers or customer routes. Some addresses are unavailable for hosts, some serve routers or shared platforms, and some may map to virtual machines or leased services. The 8,500 dedicated-server claim cannot be validated by comparing it mechanically with routed address count. Network address translation, provider-assigned space and upstream addresses all complicate the picture.
The right capacity schedule is site and product specific. For each location it should state commissioned rack power, present IT load, cooling reserve, network commit, burst capacity, storage headroom, spare hardware and the load that remains after the largest credible failure. It should also say whether disaster-recovery capacity is reserved or merely expected to be available when needed. Shared spare capacity can disappear precisely when many customers invoke it together.
The public SLA does not close the assurance gap
Serverwala publishes a service-level agreement dated July 2021. It says network, power and hardware failures are covered, support is available around the clock and hardware receives a replacement commitment. However, the public text still contains placeholders for a customer name and start date. It does not give a clear numerical availability target, measurement method, hardware replacement interval or graduated credit table in the visible agreement.
The credit mechanism is also customer-dependent. The page says credits are calculated per service, that Serverwala does not monitor every individual device for each customer and that a customer loses the credit if it waits more than one hour to report downtime. Planned, unplanned and emergency maintenance are listed among exceptions. This structure places detection and rapid notification risk on the customer while leaving the value and calculation of the remedy unclear.
The broader terms widen the gap. They exclude liability for temporary delays and outages, include third-party supplier failure among causes beyond the company's control, allow maintenance suspensions without an obligation to notify, place backup responsibility on the customer and limit liability. Those clauses are especially important in a partner estate, because utility, facility, carrier and remote-hands failures may all involve third parties. A promise of partner-backed global reach loses much of its recovery value if partner failure is excluded from the practical remedy.
There are also commercially significant continuity clauses. The terms state that overdue accounts can be terminated and customer data may be deleted soon after non-payment. They say dedicated-server deployment can take several working days and that location changes can require another payment. These may be ordinary risk controls for low-cost hosting, but they mean billing, identity verification and migration are part of the infrastructure dependency.
A serious customer therefore needs a signed schedule that overrides ambiguity. It should name the site, product, contracting entity and suppliers for which Serverwala remains accountable. It should define availability at the customer handoff, exclude only tightly bounded maintenance, provide independent measurement, specify response and restoration objectives, and preserve credits even when Serverwala's own monitoring detects the fault before the customer does. Service credits cannot restore lost revenue or data, but clear terms reveal whether the parties agree on what failure means.
Five failures expose the real operating surface
The first test is a utility outage. If the building loses grid power, the UPS must carry load through generator start and transfer. Generators must accept the actual load, cooling must remain powered, fuel must last and replenishment must be possible. A customer may see no BGP change if routers survive while compute does not. The evidence should include recent integrated tests, not separate certificates for components that have never been exercised together.
The second is cooling failure. Servers may throttle or shut down before the electrical system runs out of capacity. If the room has redundant cooling units but shared controls, pumps or heat rejection, an apparently redundant design can still fail as one system. The provider should show the maximum safe load after one component is isolated and the time available before temperatures breach limits.
The third is carrier-meet interruption. A cut fibre or failed meet-me-room switch can leave power and servers healthy but unreachable. The four upstream names around AS149573 show portfolio choice, while the route paths show that an individual prefix usually relies on one dominant immediate upstream. A useful exercise withdraws that path, observes convergence from several Indian and international networks, checks remaining bandwidth and confirms that management access survives.
The fourth is a facility fire, smoke event or flood. The priority becomes life safety, isolation and controlled re-entry. A promise of remote hands is irrelevant if the building operator closes the site. Recovery then depends on another location, current backups, replacement hardware, address and DNS control, and a team authorised to rebuild. Customers should know whether Serverwala's multi-city catalogue permits actual workload recovery or simply offers a new order at another site.
The fifth is an administrative failure. A disputed invoice, failed KYC check, compromised account or inaccessible support portal can cut off the service without any physical fault. Serverwala's public terms give account status substantial consequences. Customers need independent contact routes, named escalation officers, protected domain and DNS access, and a delay before destructive data action when a billing dispute is active.
These failures also identify who is affected. A retailer loses transactions; a streaming service loses viewers; an enterprise loses remote access; a reseller may take many downstream customers offline at once. Colocation customers can lose access to their own hardware. VPS and dedicated-server customers may lose both workload and control panel. A failure in one shared network or facility can therefore spread far beyond the number of direct contracts.
Maintenance is where claimed redundancy becomes usable or illusory
Most infrastructure does not fail first in a dramatic regional event. It fails during ordinary work: a UPS module is serviced, a generator is tested, a router receives new policy, a cross-connect is moved or cooling equipment is isolated. A resilient site allows that work to happen without putting the critical load on an unexamined single path. A fragile site discovers the common dependency only after a technician opens the wrong breaker or withdraws the wrong route.
This is why Tier III's promise of concurrent maintainability is more demanding than a count of spare components. The facility must be able to remove each relevant capacity component and distribution path on a planned basis while IT continues operating. The operator also needs accurate diagrams, switching procedures, trained staff and rollback authority. A design can contain two of everything and still suffer an interruption if the maintenance sequence or control system joins those components at the wrong point.
The partner structure makes change control harder for Serverwala. A carrier may schedule work with the facility; the facility may schedule power maintenance with Serverwala; Serverwala may then need to identify affected racks and notify customers. Each handoff consumes time and can lose detail. A generic notice about "network maintenance" is not enough if the customer needs to know whether both management and production paths share the component being changed.
The customer should ask for a forward maintenance calendar and a responsibility table. The table should name who proposes a change, who checks customer impact, who approves it, who observes the service, who can stop the work and who communicates restoration. Emergency work needs the same ownership even when notice is impossible. If Serverwala cannot compel its facility or carrier partner to provide timely information, that limitation belongs in the service design and contract.
Maintenance evidence can be sampled without exposing sensitive infrastructure. A provider can give redacted notices, method statements, rollback criteria and after-action summaries. It can show that A and B power paths were serviced separately, that a router withdrawal moved traffic as expected, and that customer monitoring agreed with facility records. It can also report near misses, because an aborted change often reveals more about operational discipline than a month of uneventful uptime.
Serverwala's public terms reserve broad maintenance rights and say notice will be attempted but is not obligatory. That protects operating flexibility, but it leaves the customer unable to plan around a potentially common-risk window. A stronger site schedule would define notice periods, emergency exceptions, maximum maintenance exposure and the circumstances in which planned work counts against availability. It would also state whether partner maintenance receives the same controls as work performed directly by Serverwala.
The decisive test is simple: ask for the last three maintenance events affecting the ordered location and compare the plan with the result. Did the remaining power and carrier paths carry the full load? Did any alarm, route change or temperature excursion occur? Were customers notified before and after? If those records are unavailable, the redundancy has not yet become evidence a buyer can rely on.
India's power build-out raises the standard of proof
The national market is expanding into a power-constrained asset class. In a February 2025 parliamentary answer, India's Ministry of Power cited 854 MW of existing data-centre IT load and estimated another 5,640 MW by the 2031-32 financial year, with most of that expected by 2027-28. The ministry said transmission planning was under way for large upcoming clusters and pointed to state policies, renewable integration and grid expansion.
Those figures do not predict an outage at a Serverwala location. They explain why a generic assertion of ample power is no longer enough. Large new loads compete for substations, transmission capacity, land, water and backup-generation permits. Connection capacity can exist on paper before energisation. A building can be complete while a utility upgrade is late. A reseller can market a future location before partner capacity is commissioned.
Rajasthan, where Serverwala is registered, introduced a Data Centre Policy in 2025 that promotes investment, renewable energy and 24-hour operation and adjusts building rules for data-centre construction. That policy can improve the environment for future assets. It is not evidence that Serverwala currently operates a data hall in Jaipur. The company's public office address and APNIC contact address are administrative anchors; no site-specific power or facility record reviewed here converts them into a demonstrated data centre.
The distinction between announcement and operation should remain strict. A policy incentive is not an energised feeder. A building approval is not commissioned IT load. A generator nameplate is not tested runtime. A rack plan is not contracted cooling. A city landing page is not a facility acceptance certificate. Capacity becomes real when the site is commissioned, measured under load, connected through independent paths and supported by people who can recover it.
Regulation adds another operational obligation. CERT-In's 2022 directions cover data centres, cloud services and virtual private server providers, including incident reporting, log retention and customer validation requirements. These duties make time synchronisation, secure logs, incident ownership and customer records part of the operating platform. A provider spread across partner sites needs a consistent way to obtain evidence from those partners quickly enough to meet its own obligations.
What would turn the claims into evidence
Serverwala can answer the ownership question with a location register supplied under confidentiality. For every location sold to a serious buyer, it should name the legal facility operator, street address, building, room or cage, service commencement date and Serverwala's contractual rights. It should separate owned equipment, leased racks, resold servers, cloud capacity and pure referral arrangements. This does not require publishing sensitive floor plans to the internet.
It can answer the power question with a site-level electrical pack: utility sources and substations, transformer and switchboard topology, UPS configuration, generator count, fuel autonomy at measured load, refuelling contracts, latest maintenance and integrated-test results. The pack should identify common components and state the load sustainable after each planned isolation or unplanned failure.
Cooling evidence should state the design and current IT load, rack-density limits, environmental range, cooling redundancy, common controls and measured recovery after loss of one unit or loop. For high-density GPU service, the provider should show that the advertised hardware can run at full contracted performance during the design failure, rather than only during normal conditions.
Network evidence should be equally specific. The buyer needs a diagram from its rack or virtual host to edge routers, carriers and building entrances; current BGP policy; committed and spare capacity; route-origin status; DDoS dependencies; and results from a carrier-withdrawal exercise. The two invalid RPKI prefixes should be corrected or withheld from single-homed critical service until route authorisation agrees with the actual origin.
Recovery evidence should show dates and outcomes. When was utility-to-generator transfer last tested under IT load? When was one UPS path isolated? When was a carrier removed? When was a server restored from backup in another location? How long did detection, escalation, access, repair and customer communication take? A redacted incident report can provide more confidence than a page full of absolute uptime language.
Finally, the contract should follow the evidence. It should attach the named site and technical schedule, keep Serverwala accountable for its chosen suppliers, define maintenance notice, report metrics automatically, state recovery objectives, preserve customer access to backups and specify exit assistance. The customer should have enough address, DNS, data and configuration control to move if the service or commercial relationship fails.
A practical buyer test
Before ordering, a customer should choose one real workload and one real location. It should ask Serverwala to identify the exact facility and contracting entity, then reconcile the answer with the invoice, service schedule and network path. A sales list of alternative cities is not a substitute for that first placement decision.
Next, the customer should probe reachability from multiple networks. It should record the originated prefix, RPKI state, immediate upstreams, latency and packet loss, then repeat the measurement during a declared carrier test. For a service on AS149573, the buyer should check whether its prefix has one dominant upstream and whether the supposed backup accepts and carries the route at adequate capacity.
The buyer should then test physical recovery. For colocation, request a remote-hands task such as identifying a port, checking a power feed or reseating a non-critical cable, and measure authorisation and completion time. For dedicated servers, test hardware replacement and console access. For cloud service, restore an application and its data into another failure domain. Each exercise should use the same escalation routes that would apply during an incident.
Power and cooling tests need documentary evidence because customers cannot safely force a building failure. Ask for recent integrated-system test summaries, maintenance records and environmental trends. Confirm that dual feeds are independent from utility entrance to rack outlet and that both power supplies are connected. Confirm that generator fuel and cooling remain available for the stated duration.
The final test is exit. Export data, configurations, logs and access records while the service is healthy. Rebuild a representative workload elsewhere. Move a test DNS name. Verify deletion and retention terms. A provider that can support an orderly exit demonstrates operational control; a provider that cannot leaves the customer dependent on the same support chain that may already be failing.
The verdict is active network, unproven facility resilience
Serverwala Cloud Datacenters Private Limited has crossed one important threshold: it operates a visible Indian network with a meaningful IPv4 footprint and several upstream relationships. AS149573, 17 current prefixes and multi-city responsive infrastructure are stronger evidence than a hosting label alone. The company also exposes purchasable rack, server and bandwidth products and identifies the Indian legal entity used for domestic billing.
The evidence weakens where the physical promise begins. Location pages describe partner agreements but do not consistently identify facilities. A Kolkata page carries German facility pricing. Tier, power, cooling and carrier claims are not tied to named site records. Four upstreams across the ASN reduce portfolio concentration, but each current prefix remains dominated by one immediate provider in public paths. Two routes have invalid origin authorisations. The public SLA leaves critical measurements and remedies unclear while excluding broad classes of interruption.
That combination supports a Medium network-evidence grade and a Weak facility-resilience grade. It is not a finding that Serverwala's sites fail. It is a finding that the public offer does not let a customer distinguish installed capacity from capacity that survives a utility outage, cooling fault, fibre cut or closed facility.
The company can close the gap with evidence it should already possess if the marketed capacity is operational: named-site schedules, partner and operator boundaries, electrical and cooling test results, carrier path maps, corrected route authorisations, incident records and customer failover demonstrations. Until then, the global catalogue is a useful sales map, not proof that any chosen rack has independent power and network recovery.