Tempest Hosting, LLC sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Tempest Hosting, LLC has a real public operating surface: AS36231 is announced, PeeringDB lists Tempest as a global content network with 1-5 Tbps of traffic, eight facility presences, and an AS set, while RIPEstat observed 19 IPv4 prefixes and 20 IPv6 prefixes at the 2026-07-15 snapshot.
• The more useful risk question is not whether Tempest exists, but which customer workloads depend on which racks, routers, local spare pools, upstream carriers, and support handoffs when a site such as Amsterdam, Dallas, London, Frankfurt, Miami, Chicago or Sydney becomes the weak point.
• Public maintenance and incident records are unusually helpful here: Tempest disclosed a London core-router migration, a Dallas cabinet and routing-equipment upgrade, a Dallas upstream-carrier fault, a Frankfurt IP issue, and an Amsterdam outage tied to a core-switch failure and delayed spare sourcing.
• The evidence supports a strong network-footprint grade, but not an unrestricted capacity claim. Installed prefixes, PeeringDB traffic bands, test files, and facility listings do not prove customer-available headroom, contractual power rights, stocked replacement hardware, or guaranteed migration time.

A hosting company can be real and still opaque at the operational layer

Tempest Hosting, LLC is the kind of provider whose public trace looks much larger than a small web-hosting brochure, yet still leaves the most expensive questions outside public view. The public identity starts with the company page in the BTW directory, but the infrastructure test begins with AS36231. RIPEstat's AS overview identifies the holder as TEMPEST-HOSTING - Tempest Hosting, LLC and marks the autonomous system as announced at the 2026-07-15 query window. ARIN-derived WHOIS data rendered through RIPEstat's WHOIS view gives the AS name TEMPEST, a registration date in May 2020, and a comment pointing to tempest.net. Those facts do not describe a product by themselves, but they establish a numbered routing boundary that can be measured independently of sales language.

That boundary is not empty. RIPEstat's announced-prefixes view returned 40 prefix timeline entries at the snapshot used here. Its routing-status view separated that into 19 IPv4 prefixes, 4,864 IPv4 addresses, 20 IPv6 prefixes, and 65,538 visible /48-equivalent IPv6 units, with full visibility from 326 of 326 IPv4 RIS peers and 322 of 322 IPv6 RIS peers. RIPEstat's neighbour view showed five observed neighbours, including four left-side relationships and one right-side relationship. A representative RPKI check for 104.152.143.0/24 returned a valid route-origin result. Taken together, those records say Tempest has an active public routing edge. They do not say how many customers sit behind each edge, which services use provider-assigned addresses, or whether the prefix count maps cleanly to server inventory.

The interconnection record gives the next layer. PeeringDB lists Tempest Hosting, LLC as AS36231, with the website https://tempest.net, IRR set AS-TEMPEST, type Content, global scope, balanced ratio, open peering policy, and a 1-5 Tbps traffic band. The PeeringDB network API gave 26 IPv4 prefixes and 30 IPv6 prefixes in the profile, while the facility API listed eight facilities: Telehouse London Docklands North, NTT Frankfurt 1, Iron Mountain Amsterdam AMS-1, CoreSite Miami MI1, Equinix SY3 Sydney, ColoCrossing CHI1, IP House London, and 365 Data Centers Richardson TX1. The corresponding exchange-attachment API returned zero public IX LAN entries for that PeeringDB network entity. That combination is revealing: Tempest presents a multi-facility footprint, but the publicly listed interconnection surface is facility-heavy rather than exchange-port-heavy.

For buyers, that distinction matters. A facility entry can mean a router, server cabinets, a transport handoff, a customer-facing service node, or a pending presence. A PeeringDB traffic band is self-reported and deliberately coarse. A prefix count can include management, anycast, game-server, customer, or reserve space. The right question is not "does Tempest have global infrastructure?" The public evidence supports that. The right question is "which physical and contractual parts turn a paid server into usable, restorable capacity in the exact market the customer is buying?"

The visible footprint is global, but the operating surface is local

Tempest's own status page is unusually concrete. The current status page showed London, Frankfurt, Amsterdam, Chicago, Miami, Dallas, and Sydney as operational on 2026-07-15, grouped across Europe, North America, and Oceania. It also displayed 30-day uptime figures: London, Chicago, Miami and Sydney at 100.0%, Dallas at 99.4%, Frankfurt at 97.4%, and Amsterdam at 84.6%. Those are not formal audited availability numbers, and they cover only the platform components represented on that page. Still, they make the service geography more tangible than a generic hosting brand would be.

The Tempest looking glass adds a second tangible point. It exposes live diagnostics from points of presence and, at the captured page, listed a Dallas test location with test IPv4 104.152.143.215 and datacenter Equinix DA1. It also exposed 100 MB, 1 GB, 5 GB, and 10 GB test files. Looking-glass evidence is useful because it invites outside measurement, yet it is narrow: a test file proves that one diagnostic endpoint exists and can be reached from where the user tests it. It does not prove the full customer estate is in the same facility, that all products have the same carrier path, or that a server ordered in another city inherits the Dallas diagnostic route.

The PeeringDB facility list makes the geography wider than the looking glass. Telehouse London Docklands North is a carrier-dense London site; NTT's Frankfurt 1 data center is presented by NTT as a large campus with 70.1 MW of critical IT load and DE-CIX access; Iron Mountain's Amsterdam AMS-1 is described as a Haarlem campus with current power and planned expansion; CoreSite's Miami MI1 is a purpose-built Miami facility connected to MI2 by lit fiber; and the Tempest page itself lists Sydney, Chicago and Dallas as operational locations. Those facility facts help explain where power, cooling, meet-me-room, cross-connect and local-access constraints enter the service. They do not prove Tempest's exact cage size, reserved power, cabinet density, or remote-hands agreement in any one site.

That is the recurring capacity problem. Installed capacity is what the network or facility can theoretically support. Usable capacity is what can be sold, powered, cooled, patched, monitored, billed, and recovered without violating an upstream, rack, power, support, or hardware-stock constraint. A global PeeringDB scope and eight facility entries may make a provider more resilient than a single-site host. They also create more places where a customer must ask site-specific questions. Which city holds the primary server? Which city holds backups? Is migration cold, warm, or automatic? Are public IPs portable between Tempest locations?

If an upstream carrier in Dallas fails, does traffic shift to another Dallas path, another North American city, or a temporary reroute with session impact?

The London migration shows what resilience actually costs

The cleanest public example of Tempest's physical dependency is the completed London network upgrade. Tempest said it was expanding into the Telehouse London data centre campus and migrating core routing infrastructure there. It also said the work would require withdrawing BGP announcements from the existing edge router, bringing a new Telehouse router online, announcing IP address space, and validating routing across upstream providers and peers. Customers were warned about connectivity drops, packet loss, and brief interruptions while routing propagated and tests were carried out.

That maintenance notice is more important than an ordinary uptime message because it shows the hidden dependency graph. The visible product may be a dedicated server, virtual dedicated server, game server or colocation service. The change that matters, however, is a router move at a carrier-neutral campus. The failure mode is not only "a server goes down." It is "the path by which the rest of the internet reaches the server is deliberately withdrawn, re-announced, and validated." A buyer who only asks for CPU, RAM and monthly bandwidth misses the path that actually makes the workload reachable.

The same notice also explains the difference between redundancy claims and redundancy proof. Tempest described benefits such as improved resilience, stronger connectivity, reduced latency, and a better foundation for future growth. Those are plausible benefits of a Telehouse presence, especially because London Docklands is one of Europe's major interconnection zones. But a maintenance notice is still a hypothesis until the customer can see how it behaves under fault. Does the London site have more than one upstream? Are route policies tested before the change window?

How much traffic moves by manual validation rather than automatic failover? Does customer support know which prefixes or products are affected? What is the recovery target if the new router fails after the old edge has been withdrawn?

The answer may be excellent, but the public record does not disclose all of it. The public record does, however, put customers in a better position than vague marketing would. A customer can track AS36231 via BGP.tools, compare public route changes against RIPEstat routing status, and watch whether the prefix set or neighbour set changes around major maintenance windows. Those tests are not a substitute for a contract, but they create independent evidence when a provider says a migration improves resilience.

Dallas exposes the rack, cabinet and upstream layers

The completed Dallas scheduled network upgrade is a second useful record because it is not only about BGP. Tempest said it would add new routing equipment and condense cabinet space so new equipment could be racked. It expected some customers' machines to be powered down and moved to other rack locations, with at least three hours of outage for enterprise dedicated customers and at least five hours for budget or blade servers. During the window, customers could also experience periodic network drops while teams worked in or around cabinets.

That is the most concrete public reminder that hosted capacity is not software floating above the building. It is bolted into cabinets, cabled to top-of-rack or aggregation equipment, powered by facility feeds, cooled by room design, and handled by people with physical access. Condensing space is an infrastructure act. It means a provider is changing the cabinet layout that makes room for growth, hardware replacement or network upgrades. It can improve future capacity, but it creates a short-term failure path in which service depends on machine moves, cable discipline, power sequencing, labelling, and post-move validation.

The Dallas routing incident adds the carrier layer. Tempest said it identified a routing issue with the Dallas network, had engaged the upstream carrier because the fault lay within that carrier's network, temporarily rerouted traffic to bring services online, and later moved traffic back to the normal connectivity path. The update also noted that some players may have experienced a brief disconnect during the transition. That language points to a customer group likely to care about latency and session continuity: game-server users or other real-time workloads. For them, "the server stayed powered" is not enough if the route resets a session or shifts latency to a path that changes the user experience.

Dallas therefore shows two different risks. The planned risk is a cabinet-and-equipment change where customers know the maintenance window and can schedule around downtime. The unplanned risk is an upstream fault where the provider must diagnose ownership, engage the carrier, reroute traffic, and later restore normal routing without making the customer impact worse. Both are recoverable; neither is invisible to customers.

A serious buyer should ask for the escalation path that corresponds to both: who can authorize an emergency reroute, who can enter the facility, who handles machine relocation, and how quickly the provider can communicate product-specific impact rather than broad city-level status.

Amsterdam is the spare-parts lesson

Tempest's Amsterdam outage is the hardest public evidence in the record because it names a very specific constraint. The incident affected Amsterdam, began as an outage investigation, and was later identified as a core switch failure. Tempest said Amsterdam was a site where it had not yet had the chance to ship a spare, so it was engaging local vendors to source a replacement. Connectivity was later restored and monitored.

That disclosure is operationally valuable. It turns the vague phrase "hardware failure" into an actionable dependency: a core switch, a spare not yet present at the site, and local vendor sourcing. For a customer deciding whether to place production in Amsterdam, the lesson is not simply that a provider had an outage. Outages happen. The lesson is that a multi-site footprint still contains site-by-site maturity differences. A site can be listed, announced, and operational while its spare pool is less complete than a more established location.

A provider can restore service, but the restoration path may depend on local procurement rather than a shelf-ready replacement.

This is where installed versus usable capacity becomes a resilience question. A cabinet can have space. A facility can have power. A prefix can be announced. None of those facts guarantee that the replacement part needed after a switch failure is already in the right city. Usable capacity includes the boring inventory that lets a service survive faults: spare switches, optics, power supplies, disks, cables, and compatible router cards. It includes remote-hands rights, vendor delivery windows, and the ability to ship across borders quickly.

In Amsterdam, Tempest's own public incident language says that spare placement was not complete at that moment.

That does not make the Amsterdam site unusable. It makes the diligence question sharper. A buyer can ask whether the missing spare was a one-time early-life issue, whether the site now has a stocked replacement, and whether other new cities have a similar gap. A buyer can also ask how services are divided by city: if an Amsterdam node fails, can the customer move to London, Frankfurt or another Tempest region without changing application architecture? Are backups already outside the site? Are IP addresses portable or only the data?

Can the customer restore from a snapshot, and if so, how long does the queue become when an entire city has a fault?

The status page turns uptime into engineering evidence

Tempest's status record is valuable because it turns availability into a dated operating history rather than a brand promise. The status page did not merely say that the company had global locations. It displayed separate service areas for London, Frankfurt, Amsterdam, Chicago, Miami, Dallas and Sydney, and it showed very different 30-day figures across them at the time reviewed here. London, Chicago, Miami and Sydney were shown at 100.0%. Dallas was shown at 99.4%. Frankfurt was shown at 97.4%. Amsterdam was shown at 84.6%. Those numbers should not be treated as audited service-level performance, because public status pages are maintained by the provider and define their own monitored components. They are still useful because they prevent the footprint from being read as a single smooth cloud. Each city has its own maintenance history, fault history and recovery behaviour.

That is especially important for a buyer comparing locations. If a provider has seven cities, a customer may assume that the cities are interchangeable. Tempest's public record argues against that assumption. Amsterdam's 30-day figure was depressed by a disclosed core-switch failure and replacement sourcing problem. Dallas had both a planned cabinet/routing-equipment upgrade and an upstream-carrier incident. Frankfurt had an IP issue. London had a planned core-router migration into the Telehouse campus.

Sydney, Miami and Chicago appeared quiet in the same status window, but public quiet is not proof of identical spare stock, identical upstream topology or identical product availability. It means the reviewed public status record did not show the same disruptions for those locations.

Status history also separates planned from unplanned risk. Planned maintenance is not simply downtime with advance notice. It is an indicator of how much physical change is occurring behind the service. The London notice shows route withdrawal, router turn-up and upstream validation. The Dallas scheduled upgrade shows machine movement, cabinet consolidation and new routing equipment. Those are signs of investment, but also signs that usable capacity sometimes requires a service interruption. A provider can expand capacity only by touching routers, cables, cabinets and machines.

Customers should therefore ask whether expansion work is scheduled by city, whether maintenance affects all products or specific product families, and whether the notice identifies IP ranges or customer groups precisely enough to plan around.

Unplanned incidents test a different part of the system. The Dallas carrier fault required Tempest to engage an upstream provider and reroute traffic. The Amsterdam failure required local replacement sourcing. In both cases the customer's experience depended on how quickly Tempest could identify the responsible layer and move to the right recovery path. A rack power fault, a failed core switch and an upstream routing fault may all look like "the server is unreachable" to a customer. They require different responders.

The provider must know whether to dispatch remote hands, open a carrier ticket, change BGP policy, replace hardware or tell the customer to restore elsewhere.

That makes status wording a useful due-diligence entity. Customers should look for whether future incidents identify location, product family, layer, workaround and final restoration. A city-level "operational" mark is good news, but a good incident report is often more informative than a green badge. It reveals whether the provider understands its own dependency stack and whether customers receive language that can be used for downstream communication. Tempest's public notices do name concrete layers in several cases, which strengthens the analysis.

The remaining gap is customer-specific: a public status page rarely tells an individual buyer whether its exact server, address block, backup and support tier are covered by the displayed component.

Frankfurt and Miami show why facility quality is not provider proof

Frankfurt is useful because the public record has two different kinds of evidence. PeeringDB lists NTT Frankfurt 1 as a Tempest facility presence, and NTT's facility page describes a large campus with carrier-neutral connectivity, DE-CIX access, redundant carrier meet-me rooms, and a major power envelope. Separately, Tempest's Frankfurt incident said an IP issue affected the Frankfurt location and was later resolved. The facility may be large and well connected, but a customer's service still depends on Tempest's own equipment, address plan, upstream choices, and support response inside or around that facility.

The same logic applies in Miami. CoreSite's MI1 page describes a purpose-built downtown Miami data center connected to MI2 by lit fiber and designed for severe storm conditions. That is valuable physical context. It tells us why Miami might be a sensible location for content, gaming or Americas-facing traffic. It also tells us nothing by itself about Tempest's exact allocation of cabinets, cross-connects, power draw, or customer migration path. A strong facility can host a weak deployment; a modest facility can host a carefully engineered deployment. Public facility pages set the physical envelope, not the provider's execution.

This distinction is especially important because customers often buy the brand, not the building. If a Tempest customer orders a server in Dallas, they may think they have bought a Tempest product. Operationally, they have bought a composite: Tempest's hardware, Tempest's router policy, a facility operator's power and access regime, one or more carriers, remote hands or local staff, support queues, billing systems, and a migration rule. When something breaks, the customer experiences the slowest accountable piece. The public incident record is useful because it tells us those pieces have surfaced in real events.

The practical diligence step is to split the service into layers. The company layer is Tempest Hosting, LLC. The routing layer is AS36231 and its observed neighbours. The facility layer is the named sites in PeeringDB and Tempest's status page. The product layer is dedicated, budget, blade, virtual dedicated or colocation capacity. The recovery layer is what happens when the product and facility layers do not match: a core switch fails, a carrier has a fault, or equipment has to be physically moved. Customers need answers at every layer, because a failure rarely respects the neat boundaries in a quote.

Route diversity is visible, but physical diversity is not

Public routing evidence is one of the better parts of this case. RIPEstat saw full visibility for AS36231 at the snapshot, and CAIDA's AS Rank page identified Tempest Hosting, LLC, the United States, a small customer cone, and a limited AS degree. IPinfo's AS36231 page, Hurricane Electric's BGP view, and BGP.tools all provide independent cross-checks for the network identity and prefixes. None of those services sees the full contractual truth, but they reduce the chance that the network is merely nominal.

The limits are just as important. RIPEstat neighbour data showed five observed neighbours. That is useful, but public BGP adjacency does not reveal whether two sessions share the same metro fiber, the same building meet-me room, the same carrier duct, or the same upstream maintenance team. It does not reveal whether a route learned from one neighbour is preferred for all traffic, whether a backup path has enough capacity for peak load, or whether a game-server workload can tolerate a shift in latency even when packet delivery returns. Routing diversity is a necessary clue; physical path diversity is a separate proof.

PeeringDB's zero public exchange attachments for the Tempest network entity also needs careful handling. It does not mean Tempest lacks interconnection, and it does not contradict a multi-facility network. PeeringDB participation is voluntary, and network records can omit private interconnects, transit, route-server sessions, or customer-specific arrangements. What it does say is that the public profile does not currently give a rich list of exchange ports the way some European networks do.

Customers should therefore ask direct questions about transit providers, private peers, backup ports, and whether each city has independent default-capable paths.

The London and Dallas records show why this matters. During the London migration, Tempest planned to withdraw and re-announce BGP routes while validating upstreams and peers. During the Dallas incident, a fault in an upstream carrier's network forced temporary rerouting. In both cases, the customer-facing effect depended not only on whether AS36231 was visible somewhere, but on which path handled the affected service at that moment. A serious resilience review should include traceroutes from customer markets, a review of route-origin authorization, prefix monitoring, and a provider explanation of what changes during a carrier outage.

Product classes fail in different ways

The public Tempest notices are also useful because they identify different customer classes. The Dallas scheduled upgrade referred to enterprise dedicated customers, budget or blade servers, and periodic network drops while teams worked around cabinets. The Dallas routing incident mentioned players who might have experienced a brief disconnect. The status page itself points to virtual dedicated servers, dedicated servers, game servers and colocation as product categories. Those labels matter because the same facility event can create different recovery tasks for each product type.

Dedicated-server customers care about the machine as an individual asset. If a cabinet is being condensed, they need to know whether their server will be powered down, physically moved, recabled or left in place. If a disk, power supply or motherboard fails, they need to know whether a compatible spare is in the same city, whether data can be preserved, and who authorizes hands-on work. The Dallas upgrade notice is concrete because it tells customers that some machines may be powered down and relocated. It also implies that the provider's growth plan had a physical layout component, not only a software provisioning component.

Virtual dedicated server customers have a different dependency. They may not care which individual chassis hosts the virtual machine until a host, storage pool or network aggregation element fails. Their recovery depends on hypervisor health, storage replication, available spare host capacity, backup freshness and migration tooling. The public Tempest record does not disclose the virtualization or storage architecture behind those products. It does, however, show why customers should ask whether a VDS can move between hosts or cities, whether backups are same-site or cross-site, and whether an IP address follows the workload during a restore.

Game-server customers care about timing as much as reachability. A temporary reroute that restores connectivity may still change latency, jitter or session continuity. Tempest's Dallas incident language about possible player disconnects is therefore important. It recognizes that a network workaround can have a user-facing effect even after the service is technically back online.

For gaming and other real-time workloads, a customer should ask where the player base is, which Tempest city is used, what the normal latency path is, what the DDoS and upstream failover path is, and whether route changes are tested from the players' markets rather than only from the provider's own monitoring points.

Colocation customers are yet another case. A colocated device may rely on Tempest for space, power, network, remote hands and cross-connect coordination, while the customer owns the server software and sometimes the hardware. If an upstream route changes, Tempest acts. If a customer device fails, the remote-hands and access policy matter. If a facility event occurs, both parties may need to coordinate. PeeringDB's facility list is helpful because it names likely physical venues, but the venue name alone does not define who can touch what, how quickly, and under which authorization process.

That boundary should be written down before an outage.

This product distinction is the heart of hosted-capacity economics. The same rack, router and support team can serve many product lines, which creates efficiency. It also creates contention during a shared incident. A core switch failure, carrier fault or cabinet move can send many customers into the same support and repair queue. Public evidence proves the layers exist; it does not prove the queue capacity. The safest customer posture is to ask Tempest for product-specific recovery language rather than relying on general infrastructure descriptions.

The same distinction should shape monitoring. A dedicated-server customer may watch power events, interface counters, disk health and out-of-band access. A VDS customer may watch snapshot age, host maintenance notices and storage latency. A game-server customer may watch player-region latency and jitter, because the Dallas routing incident shows that a recovered route can still interrupt a session. A colocation customer may watch cross-connect status, cabinet power, remote-hands response and upstream route changes. The public tools around AS36231 help with only part of that work.

They show the internet-facing edge; they do not show whether the customer's own recovery assumptions match the product class actually purchased.

Customer impact depends on workload, not just availability

Tempest's status language suggests several customer classes: enterprise dedicated customers, budget or blade server users, virtual dedicated server users, colocation customers, and players connected to game workloads. Those groups experience the same infrastructure event differently. A three-hour planned power-down may be acceptable for a test server and unacceptable for a production database. A brief route transition may be harmless for a static website and disruptive for a game session. A core switch failure may be a temporary outage for one tenant and a reputational event for a reseller with downstream customers.

That is why the affected party is not just "Tempest customers." It can include game communities, small businesses using dedicated machines as their main server, resellers whose customers do not know Tempest is underneath, developers who chose a city for latency, and companies that assumed a global provider could move them between sites quickly. It can also include peers and upstreams when route changes move traffic to alternate paths. The customer who sees an outage is often several layers away from the physical part that failed.

Data locality adds another consequence. A global service area does not tell a customer which jurisdiction holds data, which court process applies, or whether support can act locally. If a workload is in Amsterdam, the data and hardware may sit in the Netherlands even if the account is managed through a U.S. or Dubai-facing commercial interface. If a customer restores into London or Dallas, the legal and latency profile changes. Public records can identify likely sites, but only provider documentation and customer account configuration can prove where a specific workload sits.

Migration therefore has to be tested before it is needed. Customers should ask whether snapshots are portable between Tempest locations, whether public addresses can be preserved, whether cross-region backups are included or optional, and whether the provider has a documented process for emergency relocation. The public status record shows that Tempest can perform planned network moves and emergency reroutes, but it does not show customer-level recovery time for data, compute, IP address continuity, or support queue capacity during a regional event.

What proof would make the capacity claim stronger

Tempest already clears the first evidence hurdle. AS36231 is active, the prefix set is visible, the PeeringDB profile is maintained, a status page names locations and incidents, and the looking glass exposes a real test endpoint. The stronger proof would sit closer to the customer contract. It would show which products are available in which cities, which facilities host which products, which upstreams are present at each city, whether route diversity is metro-diverse, and what spare hardware is now stocked at newer locations.

The provider does not need to publish every operational detail to the open internet. Some details are security-sensitive or commercially sensitive. But customers can still ask for a private architecture note, a support escalation matrix, a current availability report, a list of maintenance windows affecting their service class, and a recovery test. They can also ask for an explanation of how the PeeringDB 1-5 Tbps traffic band maps to customer-available headroom. A coarse traffic band is not a capacity promise. It may describe peak or typical aggregate network scale, not the amount of bandwidth one customer can actually use during a fault.

The same applies to facility power. NTT Frankfurt, Iron Mountain Amsterdam, CoreSite Miami and other facility operators publish impressive power and connectivity characteristics. A Tempest customer still needs to know Tempest's committed power, redundancy level, rack density and remote-hands procedure inside the site. A facility can have spare megawatts while a specific cage has no immediate space or no compatible power whip. A facility can have many carriers while the customer's product uses one default route. A data hall can be secure while a customer restore fails because the backup was never outside the affected city.

This is the buyer's evidence ladder. First, prove the company is tied to an active network. Second, prove the product actually uses that network. Third, prove the product's city, rack, power, upstream and support dependencies. Fourth, prove the recovery path by exercising it. Tempest's public record is strong on the first step and meaningful on the third because of the incident disclosures. It is still incomplete on the second and fourth for any individual customer until the customer obtains product-specific confirmation.

The narrow verdict

Tempest Hosting, LLC should be treated as a real infrastructure operator with a measurable public network, not as a purely thin footprint. The evidence is unusually useful for a private hosting provider: AS36231 is visible; RIPEstat shows current IPv4 and IPv6 space; PeeringDB lists a global profile, a 1-5 Tbps traffic band and eight facilities; the status page names multiple operating cities; and incident records expose concrete failure paths in routers, upstream carriers, cabinets and spare hardware. That is enough to analyze the provider as infrastructure.

It is not enough to treat every advertised or implied capacity unit as already usable under failure. The public material does not disclose exact rack counts, power reservations, customer distribution by city, spare inventory after the Amsterdam failure, or the contractual terms that decide whether a customer can move data and addresses between locations. The most important lesson is that Tempest's public record shows both reach and friction. Reach comes from the global prefix and facility footprint. Friction comes from the way maintenance windows and incidents reveal the hands, parts, carriers and local decisions behind the service.

For customers, the practical test is simple to state and hard to satisfy: ask Tempest to map the exact product being purchased to a city, facility, upstream path, support queue, spare pool and migration plan. Then compare that answer with public route evidence from RIPEstat, PeeringDB, BGP.tools and the Tempest status page. If the answer is consistent and the recovery procedure has been tested, Tempest's footprint can support serious workloads.

If the answer remains generic, the buyer should assume that a server account still depends on site-specific racks, routing changes, vendor deliveries and repair windows that may become visible only when something fails.