Summary
- OLink Cloud LLC is a real registered network identity: ARIN lists AS398826 as OLINK-CLOUD, registered on 2020-09-15, and the OLink Cloud LLC organization record remains live.
- Current operating evidence is weak. RIPEstat's checked AS overview reported AS398826 as not announced, the announced-prefixes response returned no prefixes for the recent window, the BGP-state response showed zero routes, and the ASN-neighbours response showed no observed neighbors.
- Historical routing evidence is stronger than current service evidence. RIPEstat routing history shows OLink-originated IPv4 and IPv6 prefixes in earlier periods, including ARIN-allocated 172.82.16.0/22 sub-prefixes and IPv6 resources that were last seen from AS398826 on 2026-03-31.
- The public domain still has DNS life, but it does not prove an active OLink-hosted customer platform.
olink.cloudresolved to 104.165.62.200, and RIPEstat aligned that address to 104.165.62.0/24 originated by AS18779, EGIHosting. - The evidence grade is Weak: OLink has identity and historical network records, but public sources reviewed here do not prove current sellable hosted capacity, rack control, transit diversity, support readiness, data-locality guarantees or tested recovery paths.
The company exists; the operating surface is the question
OLink Cloud LLC should not be dismissed as a random name in a directory. The ARIN AS398826 record identifies AS398826 as OLINK-CLOUD and ties it to OLink Cloud LLC, with registration dated 2020-09-15. The ARIN organization record for OCL-107 shows OLink Cloud LLC as a registered organization, created in 2020 and last changed in 2024. ARIN also lists a point-of-contact record for the organization through SONGS10-ARIN. Those records are not marketing; they are registry evidence that OLink held real network identifiers and administrative responsibilities.
That is the starting line, not the finish. A registered ASN is not a cloud platform. An organization record is not installed compute. A route object is not a powered rack. For a small hosted-capacity provider, the central question is whether the company currently has a reachable service surface, current originated prefixes, visible upstreams, a customer ordering path, support contactability, and enough physical or supplier capacity to restore customers after a failure. Public records can answer part of that question, and for OLink the answer is mixed in a way that should make customers cautious.
The most current routing evidence is the weakest part of the file. RIPEstat's AS overview for AS398826 reported the holder as "OLINK-CLOUD - OLink Cloud LLC" but marked the AS as not announced for the checked time ending 2026-07-14 16:00 UTC. Its announced-prefixes response returned an empty prefix list for the recent two-week window. Its BGP-state response showed zero routes at the checked timestamp, and the ASN-neighbours response showed zero observed neighbors. Those four signals together mean the public route table did not show OLink operating an announced internet edge at that moment.
This does not prove that OLink Cloud LLC has no customers, no private contracts or no future plans. It does mean the public evidence does not support treating it as a currently observable cloud or hosting network with live self-originated capacity. If a buyer is considering OLink as a provider, the buyer should ask for fresh proof that goes beyond the registry: current prefixes, current upstreams, current customer-facing endpoints, current support procedures and current restore tests.
Without those, the provider's operational claim rests on historical network evidence and a self-maintained public profile rather than present-day BGP reachability.
Historical routing shows a real network footprint, not a current capacity guarantee
The historical record is important because it prevents the analysis from becoming too blunt. RIPEstat's routing-history response for AS398826 shows that AS398826 originated multiple prefixes over time. The history includes short-lived 31.22.104.0/24 through 31.22.107.0/24 visibility in late 2020 and early 2021, longer-lived 31.22.108.0/24 through 31.22.111.0/24 visibility into 2024, ARIN-space 172.82.16.0/24 through 172.82.19.0/24 visibility, 104.160.18.0/24 through 104.160.21.0/24 visibility, several 50.93.19x.0/24 entries, and IPv6 entries such as 2607:f358:25::/48 and 2a02:7080::/48. That is not the record of a name that never touched routing.
But historical origin does not translate into current recoverable infrastructure. The routing status for 172.82.16.0/24, 172.82.17.0/24, 172.82.18.0/24 and 172.82.19.0/24 each showed the last AS398826 observation on 2026-03-31 and no current origin in the checked output. The ARIN RDAP record for 172.82.16.0/22 still identifies OLINKCLOUD-NET as a direct allocation to OLink Cloud LLC, so the address resource exists in registry terms. The public BGP question is different: it asks whether customers can currently reach that space through OLink's AS. The checked answer was no.
The same pattern appears on some non-OLink allocated or assigned ranges. The routing status for 104.160.19.0/24, 104.160.20.0/24 and 104.160.21.0/24 showed AS398826 as the last seen origin on 2026-03-31, but no current origin in the checked output. The nearby 104.160.18.0/24 routing-status response showed a current origin of AS16509 rather than OLink. These records are best read as evidence that OLink previously used or originated externally sourced address space, not as proof that OLink still controls a live retail capacity pool.
IPv6 adds a further caution. The routing status for 2607:f358:25::/48 showed AS398826 last seen on 2026-03-31. The ARIN RDAP record for 2607:f358:25::/48 identifies an assignment associated with OLink Cloud LLC. Yet RIPEstat's prefix overview for that queried address family did not show a current AS398826 origin. The 2a02:7080::/48 routing-status response also showed AS398826 last seen on 2026-03-31, while the RPKI validation result for AS398826 and 2a02:7080::/48 still returned a valid AS398826 origin under ROA validation. That is a useful example of the difference between authorization and operation: a valid ROA can remain even when the route is not currently visible.
For customers, the historical route record creates a narrow conclusion. OLink had enough network administration to originate multiple prefixes in the past, including OLink-registered resources. It does not prove current usable capacity, and it does not prove that any customer workload can be restored into those ranges today. A buyer should treat every historical prefix as a question: who allocates it now, where is it announced, what product uses it, what upstream carries it, and what written commitment covers customer portability if OLink changes carriers or stops announcing the route?
The domain is alive in DNS but weak as a service signal
The domain surface is just as ambiguous. PeeringDB lists OLink Cloud's website as http://www.olink.cloud in its AS398826 network profile. A live DNS lookup during this review showed olink.cloud resolving to 104.165.62.200, with the same address visible for www.olink.cloud through the local resolver. Cloudflare's DNS-over-HTTPS endpoint also returned 104.165.62.200 for the olink.cloud A query. The domain also had Cloudflare nameservers and Google mail exchanger records in the resolver output. That means the domain has not simply disappeared from DNS.
But DNS is not a customer platform. HTTP and HTTPS requests to the bare domain and the www host timed out during the checked session. More importantly, RIPEstat's network-info response for 104.165.62.200 aligned the address to 104.165.62.0/24 and AS18779. The prefix-overview response for 104.165.62.200 identified the less-specific prefix 104.165.62.0/24 as announced by AS18779, EGIHosting. The routing status for 104.165.62.0/24 showed AS18779 as the current origin, and ARIN's RDAP record for 104.165.62.200 places the covering 104.164.0.0/15 allocation under EGIHosting.
That does not make EGIHosting a confirmed OLink supplier; it only says the address currently used by OLink's public DNS sits in an EGIHosting-originated prefix. The practical implication is still strong. If a customer uses the OLink domain as the first proof of service, the domain does not show OLink's own AS398826 carrying the web entry. It shows a separate hosting network carrying the address, while the website itself did not respond to web requests in the check. The domain therefore supports a weak operating signal: someone maintains DNS, but the customer-facing web or order surface is not publicly verifiable from this evidence.
This distinction matters because a hosted-capacity provider's web presence is often also its control plane. A small provider may use a billing portal, support portal and ordering page as the primary path for sales, ticketing, invoices and restoration requests. If the public web entry is unreachable, a customer should not assume that service management is healthy. It may be a temporary firewall issue, a web-server issue, a DNS misconfiguration, a deliberate access policy, a retired retail front end, or a site moving between suppliers. Public evidence cannot resolve which. It can only tell the buyer that the easy public proof is not there.
PeeringDB keeps the public profile alive, but it does not verify racks
PeeringDB is one of the few public places where OLink's intended operating self-description remains visible. The PeeringDB API record for AS398826 lists the network name as OLink Cloud, website http://www.olink.cloud, IRR as-set AS-OLINKCLOUD, general peering policy "Open", network type "Content", 50 IPv4 prefixes, 10 IPv6 prefixes, traffic in the 1-5Gbps band, balanced ratio and North America scope. It also shows no public exchange records and no facility records in the returned sets. The PeeringDB record had a netixlan_updated timestamp in 2026 and a much older netfac_updated timestamp from 2021.
That profile is not meaningless. It suggests that OLink presented itself as a North American content or infrastructure network with enough route scope to warrant an as-set, prefix counts and traffic-band information. It also gives a buyer a concrete question set: where are the advertised prefixes now, why are they not showing under AS398826 in the recent RIPEstat window, what exchanges or private interconnections exist outside PeeringDB, and which data centers host customer workloads?
At the same time, PeeringDB is a self-maintained interconnection database. A current profile does not prove current traffic. The lack of exchange and facility records does not prove OLink has no physical presence, but it removes one public corroboration path. If a provider says it sells hosting or cloud capacity, facility and exchange records help show where packets can enter the network and where equipment might sit. Here, the public profile has a brand, an ASN, an as-set and traffic claims, but not facility entries, internet exchange entries, a working website, or a matching recent BGP view.
The lack of public facility records is especially important for the article's core topic. Hosted capacity depends on racks, power and repair windows even when the provider markets the service as cloud. A route table can show a prefix; PeeringDB can show an as-set; neither proves a spare server, a cabinet, a generator, a remote-hands contract, a replacement drive inventory or a support shift. With no public facility list, the rack boundary for OLink remains unknown. Customers should ask whether OLink owns hardware, leases servers, resells a facility provider, or keeps only network identity while another operator hosts the service surface.
The route objects look stale beside the current table
RIPEstat's as-routing-consistency response for AS398826 is one of the most useful diagnostic views because it separates registration-like data from current BGP. The response listed multiple prefixes that were present in whois or IRR data but not in BGP at the query time. These included 2a02:7080::/48, 38.128.152.0/24 through 38.128.155.0/24, 104.160.18.0/24 through 104.160.21.0/24, 172.82.16.0/22 and the four 172.82.16.0/24 through 172.82.19.0/24 sub-prefixes, plus 2607:f358:25::/48. That is a clear sign of residue: records exist, but the routes were not visible under AS398826 at the checked time.
That residue matters for security and reliability. IRR and ROA records are part of routing hygiene, but stale or inactive records can mislead buyers who only search databases. A route object can survive a business change, a supplier change or a decommissioned service. A ROA can authorize an origin that is not currently announcing. A PeeringDB prefix count can remain even after a network goes quiet. None of those records should be interpreted as installed capacity without matching current route visibility and a customer-facing service path.
The prefix-level RPKI views show the same boundary. RIPEstat's RPKI validation for AS398826 and 172.82.16.0/24, 172.82.17.0/24, 172.82.18.0/24 and 172.82.19.0/24 returned valid AS398826 origins. That is positive if OLink resumes announcements because route validation would not be starting from zero. But the routing-status responses still did not show current visibility for those prefixes. Valid authorization is a foundation; current reachability is a separate condition.
For a customer, this is not an academic distinction. If a provider's own address space is not currently announced, a customer's ability to keep an IP address through a migration is uncertain. If the provider depends on another network for its website, the customer's own workload might be even more dependent on third-party hosting or reseller arrangements. If some route records are valid but inactive, the provider may be able to return them to service, but that requires routers, upstream acceptance, RPKI publication, abuse contacts, access controls, support staff and customer migration planning to be aligned at the same time.
Facility, power and supplier boundaries are not public
The weakest evidence area is the physical layer. The public sources reviewed here do not show OLink's data-center sites, rack counts, colocation contracts, power density, cross-connect partners, upstream contracts, hardware inventory, spare nodes, backup system, control-plane architecture or support escalation hours. That absence is not unusual for a small infrastructure provider, but it is decisive for risk. A cloud or VPS plan is not a free-floating unit of compute. It depends on power, cooling, cabinets, drives, switches, optical modules, transit, route policy, remote hands and someone who can fix the failed thing at the right hour.
OLink's current public profile does not let a buyer identify those dependencies. If it still sells hosted capacity, the provider could be operating through leased servers, customer-owned hardware, reseller capacity, a private facility agreement, a small colocation footprint, or a dormant network identity waiting for relaunch. Each model creates different failure paths. A reseller can lose capacity when the upstream hosting company changes terms. A small colocation footprint can fail when a cabinet, top-of-rack switch or power feed goes down. A leased-server model can hit hardware-stock delays.
A dormant network identity can preserve registry records while offering no immediate recovery path at all.
The ARIN direct allocation for 172.82.16.0/22 is the most concrete OLink-owned address resource visible in the reviewed records, and the RPKI validation results for its sub-prefixes are favorable. Yet address ownership does not identify where servers sit. A provider can own a prefix and still need an upstream to accept announcements, a facility to house equipment, and an operations team to respond. If the route is absent, customers cannot use the prefix on the public internet through that AS, no matter how clean the registry record is.
Power and repair windows are equally opaque. There is no public SLA page, status page or incident history in the reviewed material that describes how OLink handles host replacement, storage failure, DDoS traffic, carrier outages, maintenance windows or customer data export. A customer cannot infer those from PeeringDB traffic bands or route history. The only safe approach is to ask for written product-specific commitments: facility location, upstream list, backup location, restore objective, hardware replacement target, ticket escalation path, data export format and the actual AS/prefix that will carry the workload.
Transit diversity is not visible in the current table
When AS398826 is not announced, current transit diversity is not observable through ordinary BGP collectors. That is the simplest and most important conclusion from the RIPEstat current views. The AS overview says not announced. Announced-prefixes is empty. BGP-state has zero routes. Neighbours has zero observed neighbors. A buyer therefore cannot rely on public route collectors to verify whether OLink currently uses one upstream, multiple upstreams, an anycast partner, a DDoS mitigation provider or a route server. The public table does not show the paths.
Historical data and CAIDA modeling add context but not enough certainty. CAIDA's ASRank record for AS398826 marked the AS as seen and described a small cone with two ASNs, twenty-one prefixes, one provider and one customer in its model. That is useful evidence that the network has been observed in topology analysis. It does not override the current RIPEstat empty state. Models can lag, aggregate different time windows, or preserve historical inferences after a route becomes inactive. The live buyer question is not whether AS398826 ever had a provider; it is whether the exact service being bought can survive a provider change or route withdrawal today.
The historical prefix transfer pattern also raises a practical transit question. Some prefixes once seen from AS398826 now have different current origins or no current origin in the checked views. RIPEstat showed 31.22.108.0/24 and 31.22.109.0/24 currently under AS42831 in prefix-overview, while 31.22.110.0/24 and 31.22.111.0/24 aligned to other current holders. That kind of movement can be normal in leased address markets or supplier changes. For customers, it means the IP address in a server invoice may not be a durable asset unless the contract says so.
A provider can change upstreams or address suppliers; the customer may then have to re-address, update DNS, rebuild reputation, or migrate during a deadline.
The traffic risk is not limited to outages. IP reputation, abuse handling and geolocation can also break a hosted application. If a customer is assigned an address from a leased or supplier-controlled range, email reputation, fraud-scoring, regional classification and blocklists may not follow the provider's brand. If the provider later changes the range, the customer may lose allowlists or encounter new reputation debt. OLink's current public evidence does not show a stable, live customer prefix pool, so these risks should be treated as open rather than resolved.
Hosted capacity economics are unforgiving when public proof is thin
The economic problem behind this profile is simple: small hosted-capacity providers can look inexpensive because they do not publish all the resilience that customers silently expect. A buyer may see a cloud or VPS brand and assume that capacity can be replaced quickly. In reality, every replacement depends on spare hardware, storage availability, IP space, support labor, upstream acceptance, DNS control and payment or account access. When public evidence is thin, the buyer cannot tell whether the advertised price reflects efficient operations, reseller leverage, spare capacity, or simply a lack of disclosed recovery commitment.
For OLink, no reviewed public page showed a current product catalogue, available stock, CPU tiers, storage classes, bandwidth commits, backup options or status monitors. That absence forces a different kind of underwriting. Instead of comparing plan sizes, a buyer has to start with existence questions. Is the company currently selling hosting, VPS, bare-metal, proxy, CDN or content infrastructure? Which public endpoint is authoritative? Which AS and prefixes serve customers? Which facility or supplier hosts the machines? What does the customer receive if AS398826 is not announcing at order time?
Can the provider show recent external monitoring from multiple networks?
The difference between installed capacity and usable capacity is critical. Installed capacity is the hardware or supplier allocation a provider may have. Usable capacity is what can be ordered, powered, routed, monitored, supported and restored. A provider could have a direct allocation and no spare server. It could have a server and no currently announced prefix. It could have a route and no working billing portal. It could have a domain and no accessible support system. The public record for OLink shows enough fragments to justify continued monitoring, but not enough to prove usable hosted capacity for a production workload.
This is why the article title emphasizes racks, transit and repair windows. If OLink is operating today through third-party hosting or private arrangements, the customer's service still sits somewhere physical. If the OLink-owned prefix is absent from BGP, the route still has to be restored or replaced. If the website is unreachable, customer communication still has to happen through some other path. If a provider uses supplier address space, the supplier's policies can become the customer's outage. These are not theoretical concerns; they are the normal hidden cost of buying infrastructure from a thinly documented provider.
Data locality is unresolved, despite a North American profile
The assignment uses a global category because cloud and hosting services can be ordered across borders, and because the directory entry is a public infrastructure entity rather than a local retail storefront. OLink's PeeringDB profile, however, lists North America scope, and ARIN records place the organization in the United States. That gives a rough regional signal but not a data-locality commitment. A customer cannot infer where disks, snapshots, logs, tickets or backups reside from an ASN registration.
The DNS evidence points to an EGIHosting-originated address for the public domain. EGIHosting is a US-oriented hosting network, and ARIN's covering allocation for 104.164.0.0/15 is registered to EGIHosting. That supports the idea that the public web surface currently depends on a US hosting provider, but it still does not say where customer workloads would be hosted if OLink sells them. The domain host can be different from customer servers. A support portal can be in one network while VPS nodes sit in another. Mail can use Google while infrastructure runs elsewhere.
The reviewed evidence does not connect those components into a verifiable locality map.
For regulated or locality-sensitive buyers, that is not enough. They need to know whether data is stored in the United States, whether any support exports leave the country, whether backups are in the same jurisdiction as primary storage, whether IP geolocation matches customer expectations, and whether the provider can give written commitments about data export and deletion. Public registry records and a domain A record cannot answer those questions. If OLink's current operating model involves leased infrastructure, the supplier's locality, subprocessing and incident-handling terms become part of the customer's risk surface.
The safer conclusion is that OLink has a US-centered registry and public-profile footprint, not a proven global hosting locality offer. Buyers outside North America should not treat the "Global" category as a promise of global facilities. Buyers inside North America should still ask whether the exact workload is in California, another US state, Canada, Europe, or an upstream supplier's undisclosed location. Data sovereignty begins with where the bytes and logs actually sit, not with the country of an ASN contact.
What evidence would move the grade
OLink's evidence grade could improve quickly if current operating proof appears. The first needed item is live routing: AS398826 announcing at least one OLink-controlled prefix, visible through RIPEstat announced-prefixes, BGP-state and neighbor views, with valid RPKI and a current upstream list. If OLink does not intend to use AS398826 for customer services, it should state which AS or supplier network is authoritative. Silence leaves customers guessing whether the provider is dormant, outsourcing, transitioning or operating privately.
The second item is a working customer-facing surface. A public site, status page, product catalogue, support page or ordering portal should be reachable and should describe what is actually sold. For a hosting provider, product descriptions need to identify more than CPU and storage. They should describe facility geography, backup options, DDoS handling, IPv4 and IPv6 availability, service limits, restoration expectations and support channels. If the provider is not currently taking retail orders, saying so would be more useful than leaving a timed-out domain.
The third item is physical and supplier transparency. OLink does not need to publish rack diagrams, but it should be able to tell serious buyers where the service runs, who owns the hardware, who controls the network edge, which upstreams carry traffic, what facility or server supplier is used, whether spare machines exist, and what happens during hardware shortage. A single-page infrastructure statement would materially improve trust because it would connect the registry identity to operational reality.
The fourth item is recovery evidence. Customers should ask for a recent restore test, backup-retention policy, ticket escalation path, maintenance communication policy and data-export procedure. In small hosting, the failure often appears as a slow restore rather than a spectacular outage. A provider that can demonstrate a tested restore from one host to another, with DNS, IP, disk image and customer notification steps, is far safer than a provider that only shows old route history.
The fifth item is incident history. A public status page with resolved incidents, maintenance windows and monitor definitions would help customers distinguish a temporary website problem from a broader service question. It would also show whether the provider communicates during downtime. Without incident history, the buyer cannot know whether OLink has recent operational discipline or only retained network records.
Why a quiet network can still create customer risk
A quiet or weakly visible network is sometimes safer than a noisy one: it may simply mean the company is not currently selling public hosting. The risk begins when a buyer treats the quiet record as if it were an active service. In that case, the buyer may build a continuity plan around resources that are not actually reachable, not staffed, not stocked or not under the provider's direct operational control. OLink's public profile creates exactly that ambiguity. The registry and historical route evidence say the company has held network resources.
The current BGP and web evidence do not prove that those resources are presently available to customers.
One practical risk is procurement confusion. A buyer may find the PeeringDB profile, see the traffic band and prefix counts, and assume there is a working North American hosting platform behind the name. If the buyer then receives a private quote, the buyer might not realize that the quote needs fresh proof of route origin, facility placement and support escalation. A dormant or transitioning network can still sell capacity through another supplier, but then the supplier's contract becomes the real continuity boundary.
The buyer should know whether it is buying from OLink-owned infrastructure, OLink-managed leased servers, a reseller arrangement, or a third-party host with OLink branding.
A second risk is address continuity. The article's routing evidence shows that some prefixes historically seen from AS398826 are no longer current OLink-originated routes, while the company's public domain points into a different network. If a customer uses IP addresses assigned through a thin provider, the customer's service may inherit a future renumbering event. Renumbering is not just a DNS update. It can affect allowlists, mail reputation, API clients, geolocation, firewall rules, monitoring targets, TLS certificate validation, abuse contacts and customer documentation.
If the provider cannot say whether the assigned address is from OLink's direct allocation, a leased pool or an upstream provider, the buyer cannot price that migration risk.
A third risk is recovery sequencing. A provider with no visible current AS path may still be able to restore service by moving workloads to another host, but the steps will be manual and dependent on supplier cooperation unless a tested design exists. The order matters: recover storage, power or boot the server, restore control-panel access, assign or replace IP addresses, publish DNS changes, remove stale blocks, notify customers and prove application health from outside the provider's own network. If any of those steps relies on a web portal that is itself unreachable, the customer's recovery time can stretch.
The OLink public evidence does not show that this sequence has been tested.
A fourth risk is support discoverability. A provider can have excellent private support for existing customers while showing little public surface. That is possible. It is also unverifiable to a new buyer. If the public website times out and no current status page is visible, the buyer should ask for direct support contacts, escalation names or roles, emergency channels and expected response windows before any purchase. These are not bureaucratic details.
When a rack loses power, a host fails, an upstream filters traffic or a supplier contract changes, the difference between a recoverable incident and a long outage is often the ability to reach someone who can make a routing, facility or hardware decision.
The fifth risk is evidence drift. Infrastructure records age unevenly. ARIN may still be accurate for ownership. PeeringDB may still show an old traffic band. RPKI can still validate a route that is not being announced. DNS can point to an address whose web service does not answer. A route history can look substantial even after the operating model changes. Buyers need to read these sources together, not individually. For OLink, the combined reading is that identity and history are credible, while current operating proof is missing.
That should change the procurement posture from "compare plans" to "verify whether a plan exists and how it is recovered."
The minimum diligence before using OLink for a live workload
Before placing even a modest production workload with OLink, a buyer should ask for evidence that maps directly to the public gaps. The first request is a live route proof. OLink should be able to identify the exact customer prefixes, the AS that will originate them, the upstream providers, the RPKI state and the monitoring view that confirms global reachability. If AS398826 is not the production AS, the provider should explain why the public OLink AS is inactive and which network is actually responsible for customer packets.
The second request is a facility and supplier map. The buyer does not need confidential cage photos, but it needs enough information to understand dependency concentration. Are servers in one data center or several? Are they OLink-owned, rented monthly, dedicated from a supplier, or virtualized on another host's platform? Is storage local to one node, shared across nodes, or backed up offsite? Are backups inside the same facility, another facility, or a different supplier? If a facility denies access or a server supplier suspends service, who has authority to restore the workload?
The third request is a restore demonstration. A small provider can earn trust by showing that it can restore a representative VM, site or server from backup into a clean environment and document the elapsed time. The buyer should not accept a generic backup promise as a restore promise. It should ask whether snapshots are application-consistent or crash-consistent, whether full images can be exported, whether the provider can restore to a different host class, and whether the customer can retrieve data if the billing or support portal is unavailable.
The fourth request is a communication plan. If the public website is unreachable during normal checks, the customer needs a different path for incidents. That path should include ticketing, email, phone or chat, and an emergency escalation route. It should also define how planned maintenance is announced, how route changes are communicated, how abuse or DDoS events are handled, and how the provider reports an outage caused by an upstream supplier. For a small host, communication can be as important as redundancy because customers often need to move quickly while the provider repairs the primary path.
The fifth request is a written exit path. Hosted capacity should not trap the customer. OLink should be able to state how a customer exports disks, files, databases, DNS zones, logs and account records; how long the provider retains terminated data; whether IP addresses are portable; and what happens if the provider can no longer announce a prefix. If the provider uses supplier-owned addresses, the customer should assume addresses are not portable unless the contract says otherwise.
If the provider uses OLink's direct allocation, the customer should still confirm whether that allocation is currently routed and whether it can be carried by more than one upstream.
These diligence steps are not meant to punish a small provider. They are the minimum needed when public evidence is thin. A small host can be reliable if it is honest about its footprint, conservative in what it sells, and disciplined in how it restores customers. The problem is not smallness. The problem is an unverified gap between a registered network identity and the current ability to deliver, route, support and recover a hosted workload.
The practical buyer read
OLink Cloud LLC has enough public infrastructure evidence to remain on the map: ARIN identity, OLink-registered address resources, historical AS398826 routing, valid RPKI for some OLink-associated prefixes, PeeringDB presence, DNS for the company domain, and CAIDA topology traces. Those facts justify a monitored directory entry and a company research note. They do not justify assuming that OLink currently sells recoverable hosted capacity.
The public red flags are specific. AS398826 was not announced in the checked RIPEstat AS overview. Recent announced-prefixes was empty. BGP-state had zero routes. ASN-neighbours had no observed neighbors. Multiple historical prefixes had last AS398826 observations on 2026-03-31 or earlier. The domain's A record pointed at an EGIHosting-originated prefix rather than OLink's own AS, and web requests timed out. PeeringDB listed no exchange or facility records. No public product, status, SLA, facility or support page was reachable in the reviewed material.
For a lightweight, non-critical experiment, a buyer might still investigate OLink directly and ask for current proof. For production workloads, the burden of proof should be higher. The buyer should require current BGP evidence, product-specific facility location, current support contacts, backup and restore terms, upstream and DDoS path disclosure, IP portability terms, and a clear migration plan if AS398826 remains inactive. If the provider cannot supply that evidence, the customer should treat OLink as a historical or dormant network identity rather than a dependable primary host.
The final evidence grade is Weak. OLink Cloud LLC is not a blank record, and the historical routing footprint is real. The current public operating evidence, however, is too thin to prove hosted capacity, rack control, route diversity, installed spare inventory, customer support readiness or data-locality assurances. The sensible watchpoint is not whether OLink once existed in routing records.
It is whether AS398826, the OLink domain and any customer service surface become visibly reachable again with enough detail to show how a hosted workload would survive a rack, upstream, hardware-stock, support, billing, migration or provider-contract failure.