Vertex Connectivity is visible as an Asia-Pacific hosting and transit network, not a local access ISP

Summary

• Vertex Connectivity LLC is not merely a dormant company name. ARIN registers AS149513 and a directly allocated IPv4 block to the Boulder, Colorado company, RIPE NCC records a second Vertex ASN, and public route collectors saw AS149513 reachable through every one of their IPv4 and IPv6 peers at the research cut-off.
• The physical footprint is not a local broadband access network. Vertex's self-reported interconnection record places AS149513 in ten data centers and on five exchange fabrics across Hong Kong, Tokyo and Los Angeles, with a stated Asia-Pacific scope and the SyCloud routing name. No public evidence establishes poles, towers, fibre drops, customer-premises equipment or a local household service area.
• Diversity is visible in the control plane but unproven in the ground. Public paths reach AS149513 through PCCW Global, NTT, HGC Global, China Unicom Global, SoftBank, Hurricane Electric and other networks, yet several links may converge inside the same Hong Kong facilities, metro ducts, cross-connect providers or submarine-cable routes.
• The network evidence grade is Medium: current routing and exchange presence are strong, but installed capacity, traffic, owned equipment, facility contracts, route separation, backup-power exposure, staffing, customer terms and measured restoration remain undisclosed. The correct resilience question is how SyCloud keeps a multi-city hosting and transit service alive, not how a regional ISP repairs a local last mile.

The first visible failure boundary is a meet-me room

The most concrete public sign of Vertex Connectivity is not a radio on a tower or a fibre drop outside a house. It is an internet-exchange address. Vertex's PeeringDB record for AS149513 reports a 100 Gbps connection to Equinix Hong Kong, 100 Gbps connections to BBIX in Tokyo and the western United States, and 10 Gbps connections to Equinix Tokyo and the Hong Kong Internet Exchange. The record also lists ten data-center presences: six in Hong Kong, two in Tokyo and two in downtown Los Angeles.

That geography changes the entire infrastructure analysis. A regional access provider collects monthly payments from homes and businesses in a bounded service area, then maintains the cable, radio, pole, cabinet or customer equipment needed to reach them. Vertex's visible network instead sits where autonomous systems exchange routes and traffic. Its public customers, if any, are not identified, but routing observations show other autonomous systems behind it. A failure may therefore affect hosted servers, address-space users, downstream networks or resellers scattered far from the room where the fault occurs.

The company's physical dependency begins with racks, routers, optical interfaces and cross-connects inside third-party facilities. Those facilities need utility power, reserve power, cooling, security and controlled technician access. Metro transport must connect the buildings. Long-haul and submarine systems must connect Hong Kong, Japan and the United States. External carriers must accept and propagate Vertex's routes. Configuration, filtering and route-origin authorisation must remain correct.

A port can stay electrically lit while traffic fails because a route was withdrawn; a route can remain visible while congestion or a cross-connect fault makes service unusable.

This distinction is not semantic. It decides which redundancy claims matter. A second tower would matter to a wireless access provider. For Vertex, a second BGP neighbour matters only if it reaches a different router over a genuinely separate circuit, in a facility that does not share the same vulnerable plant. A second exchange membership matters only if traffic can move there with enough spare capacity. A Los Angeles presence matters only if the routes, services and customer sessions that normally depend on Hong Kong can be restored or shifted across the Pacific.

The evidence therefore contradicts the idea of a local connectivity bill whose resilience depends on access repair. There is no verified local bill, local service radius or access plant in the public record. There is, however, a live interconnection fabric with real operational dependencies. The responsible course is to analyse the network that can be observed and mark the retail-access thesis as unsupported.

What can be tied to the company

The legal and number-resource identity is stronger than the commercial identity. ARIN's record for AS149513 names Vertex Connectivity LLC, uses the handle VCL-147-149513, and dates the current ARIN registration to 26 September 2023. The associated ARIN organisation record gives 1942 Broadway Street, Suite 314C, Boulder, Colorado, and uses a syhots.com contact address. ARIN also records 23.158.104.0/24 as a direct allocation to Vertex, registered in July 2023.

Those records establish administrative control over number resources. They do not prove that Boulder contains a network operations center, router, customer or employee. The same suite appears in public records for many unrelated businesses and is used by a company-registration service. It is best treated as a legal and correspondence address unless a facility, staffing or equipment record establishes more. No such Boulder operating evidence was found.

The company's second registered network identity reinforces the legal link while exposing a more complex operating history. The RIPE NCC record for AS197547 names Vertex Connectivity LLC, cites Colorado registration number 20231678240 and repeats the Boulder address. It lists the autonomous system under the short name Vertex. The RIPE record is current administratively, but current global routing observations no longer show AS197547 originating Vertex's directly allocated IPv4 block.

The public route history is unusually informative. RIPEstat's history for 23.158.104.0/24 shows AS197547 originating the block from July 2023 through 18 May 2026. AS149513 began originating it on 7 May 2026, creating a short overlap before becoming the sole observed origin. At the cut-off, RIPEstat's routing-status result saw AS149513 as the current origin and the prefix from every one of its 327 IPv4 collector peers.

That sequence is consistent with an origin migration between two autonomous systems registered to the same legal company. It does not disclose why the change occurred, which routers moved, whether customer sessions were migrated, or whether the two ASNs represent different products or operating teams. It does show active route management in May 2026. The company's network identity is not frozen in a registry; its principal directly allocated block moved from one Vertex ASN to another while remaining globally reachable.

Vertex's public-facing network name is SyCloud. BGP.Tools labels AS149513 as SyCloud, while PeeringDB links the company to syhots.com and the route set AS149513:AS-SCLOUD. The public AS-set record contains AS149513, AS197547 and several other networks. An AS-set is routing-policy data used to describe routes that may be accepted or announced; membership does not by itself establish ownership. It does, however, support the conclusion that Vertex presents AS149513 as the center of a broader routing customer or partner set.

The result is a precise identity judgment. Vertex Connectivity LLC is a Colorado-registered network resource holder associated with AS149513 and AS197547. AS149513 is active under the SyCloud name. The public evidence does not establish that SyCloud is a separate legal company, and this article does not create one. It is treated as Vertex's visible network brand because the company's own interconnection record and routing-policy entities use that name.

A live network, but not the one the name suggests

As of 10 July 2026, AS149513 was strongly visible. RIPEstat's AS routing status counted 18 IPv4 announcements covering 4,096 addresses and nine IPv6 announcements covering 65,542 equivalent /48 units. It reported full visibility among 327 IPv4 peers and 321 IPv6 peers. Its announced-prefix list included Vertex's own 23.158.104.0/24 alongside blocks registered through several other organisations and registries.

Independent views broadly agree on current operation while differing on counts and labels. Hurricane Electric's BGP Toolkit reported 27 originated IPv4 prefixes, 11 IPv6 prefixes and 53 observed peers in its early-July view, including more-specific announcements. CAIDA's AS Rank saw a network degree of 34, with seven providers, 23 peers and four customers, and a customer cone of five autonomous systems. Cloudflare Radar provides another current routing view. Differences among these sources are normal because they sample different collectors, count aggregates and more-specifics differently, and infer commercial relationships rather than reading contracts.

The consensus is still strong: AS149513 is not inactive. It originates both address families, is visible globally and appears to provide connectivity beyond its own prefixes. That supports an operating network conclusion. It does not establish a retail service. BGP carries routes for home broadband, cloud platforms, universities, hosting companies, content networks and private enterprises alike. An ASN being tagged as an "eyeball" or "Cable/DSL/ISP" network by a directory is a classification signal, not proof of a single residential subscriber.

The address mix points away from a conventional local access network. Vertex directly holds only one of the visible IPv4 /24s identified in its ARIN record. Other current announcements include address space registered to Infinite Portal, Horizon Edge, Japan Network Information Center, Shenzhen Lesuyun Network Technology, Hong Kong Broadband Network and private customers. The geofeed published from Vertex's ARIN record places some prefixes in Hong Kong, some in Tokyo and others in Los Angeles. A geofeed is an operator-supplied location hint for addresses, not a map of owned fibre or buildings. Combined with the facility list, however, it confirms a three-market hosting and interconnection pattern.

Third-party network classifiers identify the traffic as hosting. IPinfo's AS149513 profile labels the network as hosting, reports responsive addresses in Hong Kong and Los Angeles, and identifies several downstreams. BGP.Tools also places the originated prefixes under a server-hosting heading. These labels can be wrong at the margin and cannot reveal each end user's activity. They are nevertheless more consistent with the facility and address evidence than a household broadband interpretation.

No public product catalogue, residential plan, business access tariff, coverage map, installation process, service-level agreement or customer-support page was available at the linked website. The apex syhots.com domain had active name servers and an MX record at the cut-off, but no A or AAAA record; www.syhots.com returned no DNS record. The domain's registration record remained current, and recent wildcard certificates indicated that other subdomains may still be used. A missing public homepage therefore shows commercial opacity, not network shutdown.

This status distinction matters. Vertex has strong operating evidence at the routing layer and weak disclosure at the product layer. It is reasonable to say the network is live. It is not reasonable to say who can buy it, what they buy, where service is contractually delivered, or what repair promise applies.

The footprint is a triangle, not a service territory

PeeringDB lists ten interconnection facilities for AS149513. Hong Kong is the largest cluster: Equinix HK1, HK2 and HK3; MEGA-i; HKCOLO's Sino Favour Centre; and iTech Towers 2. Tokyo has Equinix TY2 and TY8. Los Angeles has CoreSite's One Wilshire facility and Digital Realty at 600 West 7th Street. The corresponding exchange-presence record lists HKIX, Equinix Hong Kong, Equinix Tokyo, BBIX Tokyo and BBIX US-West as operational.

These are self-reported interconnection records. They are useful because they name specific buildings, fabrics, IP addresses and nominal port speeds. They are not an audited asset register. A network can buy a remote exchange port through another carrier without owning a router in every listed room. A facility listing may represent a physical cage, a shared cabinet, a cross-connect to a partner, a virtual router or a transport service terminating elsewhere. The public data does not distinguish those cases.

The Hong Kong cluster is nevertheless too coherent to ignore. AS149513 has addresses on HKIX and Equinix Hong Kong, reports multiple local facilities, uses a Hong Kong country marker in one version of its AS-set, and originates address space geofed to Hong Kong. The HKIX entity view also lists AS149513 at the exchange. This is the network's clearest operating center of gravity.

Tokyo provides a second Asian metro and two reported exchange attachments. One port is listed at Equinix Tokyo and another at BBIX Tokyo, with facility entries at TY2 and TY8. That is more than a marketing dot, but it does not establish two fully independent Tokyo nodes. The BBIX port might be reached by transport from one router; the Equinix port might share the same building power, metro carrier or optical path. Conversely, a network can have unlisted equipment and routes. Public interconnection data reveals the endpoints, not the fibres between them.

Los Angeles supplies a trans-Pacific edge. One Wilshire and 600 West 7th are distinct downtown carrier buildings, and BBIX US-West is reported at 100 Gbps. Vertex's geofeed places three current /24s in Los Angeles. That combination supports an operating presence in the metro. It does not prove that the two buildings have independent power feeds, diverse paths to cable landing stations, separate routers or enough spare capacity to take over Hong Kong traffic.

Installed presence must be separated from usable service. A 100 Gbps exchange port can be provisioned and operational while carrying little traffic. A router can have several 100 Gbps interfaces while its long-haul circuit is smaller. A port may be protected at the exchange but reached through one metro wave. Conversely, traffic can exceed one port's rate by using private interconnects and transit links not shown in PeeringDB. Without interface utilisation, committed information rates, transport diagrams and failover tests, the public port list is a topology clue rather than a capacity statement.

This is why the triangle should not be drawn as a backbone map. The records place Vertex at or connected to ten facilities in three metros. They do not identify the long-haul routes, cable systems, wavelengths, leased providers, router pairs or service demarcations connecting those points. The physically honest picture is a set of evidenced endpoints joined by unknown transport.

Two hundred gigabits of claim is not two hundred gigabits of recovery

Vertex's PeeringDB entry reports 200-300 Gbps of traffic, a balanced inbound-outbound ratio, 1,000 IPv4 prefixes and 500 IPv6 prefixes. It also declares an open peering policy without required contracts or co-location. These fields are supplied by the network entity. They may be intended as peering guidance rather than audited operational measurements.

The prefix fields are especially revealing. Current route collectors saw 18 IPv4 and nine IPv6 announcements at the cut-off, not 1,500 originated prefixes. Peering networks often publish generous suggested prefix limits so that future growth or customer more-specifics do not trigger filters. BGP.Tools explicitly presents 1,000 and 500 as suggested limits. Reading them as current originated routes would overstate Vertex's routing scale by orders of magnitude.

The traffic band has a different limitation. PeeringDB describes broad traffic levels; it does not publish a time series, a measurement point or the share carried at each metro. A 200-300 Gbps network-wide level could fit within the three listed 100 Gbps exchange ports only if utilisation and direction aligned perfectly, and real networks also use transit and private interconnects. Nothing in the record shows how much of the band is actual peak traffic, customer commit, interface potential or a stale estimate.

Recovery capacity is narrower still. Suppose Hong Kong carries most normal traffic and Tokyo is the alternate. Tokyo's two reported exchange ports total 110 Gbps nominally, before allowing for transport, protocol overhead, bilateral policies and congestion. That arithmetic does not prove a shortfall because private capacity may exist and the public traffic band may be approximate. It does show why adding port labels cannot answer the failover question. The useful metric is traffic that can be rerouted after the largest credible failure while meeting latency and packet-loss objectives.

The same logic applies inside Hong Kong. Equinix Hong Kong is listed at 100 Gbps and HKIX at 10 Gbps. If those connections terminate on separate routers in separate buildings and reach independent transit paths, they can provide meaningful diversity. If the HKIX port is delivered over transport into the Equinix router, or both paths share one metro circuit, the smaller port adds route choice without removing the common physical dependency. Only the network's circuit inventory and shared-risk groups can settle that distinction.

The observed route data proves reachability, not quality. RIPE RIS saw AS149513 from all sampled peers. That says the internet knew a path. It does not disclose round-trip time, packet loss, jitter, congestion, route flaps or filtering mistakes. It also cannot show whether an application behind a prefix was healthy. A prefix can remain globally announced from Los Angeles while its Hong Kong servers are unreachable behind the edge.

Capacity claims should therefore be scored in layers. Nominal exchange ports are installed interface capacity. Observed prefixes are control-plane reachability. The self-reported traffic range is a commercial-scale signal. Usable capacity is what applications can actually send at the busy hour. Recoverable capacity is what remains after a router, facility, carrier or metro fails. Only the first three have public evidence, and even those rely partly on entity-maintained records.

Many upstreams can still share one route

Public paths show substantial logical diversity. RIPEstat's neighbour view observed AS149513 beside PCCW Global, NTT, HGC Global, China Unicom Global, SoftBank, Hurricane Electric, China Mobile International and several other networks. BGP.Tools classifies six prominent networks as upstreams: PCCW Global, NTT, HGC Global, China Unicom Global, SoftBank and Hytron. CAIDA infers seven providers and 23 peers.

That is materially stronger than a single visible upstream. It means outside collectors receive Vertex-originated routes through multiple autonomous systems, and it gives Vertex more than one policy path to important destinations. Open exchange peering can shorten routes and reduce paid transit demand. Multiple providers can also let the operator shift advertisements when one network has a routing or commercial problem.

The limits are physical. BGP records autonomous-system sequences, not conduit maps. PCCW Global and HGC may meet Vertex in the same Hong Kong carrier hotel. NTT and SoftBank may be reached through transport that shares a cable landing route. A route visible through Los Angeles may still depend on one trans-Pacific system for traffic returning to Hong Kong. Multiple sessions on one router fail together when the router, line card, power feed or configuration fails.

The distinction is well established in resilience guidance. CISA's Ten Keys to Obtaining Resilient Local Access Network Services warns that nominally redundant circuits can share physical links or facilities and recommends validating path, entrance and termination diversity. The document addresses public-safety communications, not Vertex. Its engineering principle applies directly: separate invoices and separate AS paths do not guarantee separate failure domains.

Vertex's three metros create four levels at which diversity should be tested. First is router diversity within a facility: two sessions on one device do not survive that device. Second is facility diversity within a metro: two buildings help only if transport and operations can continue independently. Third is metro diversity: Tokyo or Los Angeles must be able to carry the routes and services normally anchored in Hong Kong. Fourth is long-haul diversity: inter-metro circuits must avoid the same cable, landing station, provider core or maintenance window where practical.

The public record verifies none of those layers end to end. Ten facility listings are not a ring diagram. Five exchange ports are not a failover test. Twenty-eight observed neighbours are not 28 physical exits. The route diversity is encouraging, but it should be described as logical diversity until physical separation and recovery capacity are documented.

Hong Kong is both an advantage and a concentration

Hong Kong gives Vertex access to a dense interconnection market. The network can reach regional carriers, global transit providers, content networks and other hosting operators without hauling every packet to another country. Six listed facilities and two local exchanges create options for cross-connects and metro placement. For customers serving East and Southeast Asia, that can reduce latency and improve route choice.

The concentration is equally clear. Six facility names do not mean six independent systems. Equinix HK1 and HK3 are both listed in Tsuen Wan; HK2 is in Kwai Chung; MEGA-i, HKCOLO and iTech Towers sit elsewhere in the Hong Kong market. They can differ in power, ownership and building risk while still sharing metro fibre corridors, carrier networks and external cable systems. A major metro transport fault, prolonged power constraint, control-plane error or access restriction could affect several sites at once.

The facility operator boundary matters here. Vertex does not publicly claim ownership of any listed data center. The likely model is colocation, cross-connect purchase, remote peering or leased transport. Under those arrangements, Vertex controls its router configuration and perhaps its own rack equipment. The landlord controls the building shell, security, much of the electrical and cooling plant, and access procedures. Carriers control circuits beyond the demarcation. Exchange operators control the shared switching fabric. A fault ticket can cross four organisations before repair begins.

Reserve power is similarly layered. A data center may have generators and batteries, but the customer's rack distribution, router power supplies, optical amplifiers, meet-me room, metro carrier node and cable landing equipment all need protection. A well-designed router with dual feeds can still fail if both feeds trace to one distribution path. A generator can run while a cooling or fuel-delivery problem forces load reduction. CISA's resilient-power guidance stresses the dependence of communications on correctly sized, tested and fuelled backup systems. Again, that is a design benchmark, not proof of Vertex's installation.

Operational access can become the limiting resource even when hardware spares exist. Replacing an optic in a Hong Kong cage may require a Vertex employee, a contracted remote-hands technician or landlord staff. A fibre fault may require the metro carrier. A route leak may require a network engineer with configuration authority. A customer-facing server fault may belong to the downstream, not Vertex. Recovery time is the sum of detection, ownership triage, access approval, travel or remote-hands dispatch, replacement and validation.

No public Vertex support hours, staffing locations, remote-hands agreements, spare inventory, maintenance policy or restoration targets were found. The active ARIN contact was validated in January 2026, which is useful administrative evidence. It is not an operations rota. The missing public homepage further limits a customer's ability to find service terms or an independent status channel.

The right labour question is therefore not whether Vertex has local pole crews. It is whether the operator has authorised engineers and contracted hands in each listed metro, with configured spares and clear demarcation procedures. That is a materially different operating model from residential field repair.

The May origin change is the most useful recovery clue

The transition of 23.158.104.0/24 from AS197547 to AS149513 offers a rare glimpse of network change. For nearly three years the directly allocated block was visible through AS197547. In May 2026, both Vertex ASNs originated it for roughly eleven days, after which AS149513 remained. The final state was globally visible and carried a route object in the ARIN system.

An overlap can be a controlled migration technique. Advertising the same prefix from old and new origins allows operators to test reachability and shift traffic before removing the old path. It can also create routing-policy problems if filters or route-origin authorisations accept only one ASN. Without change records, it is impossible to know whether the overlap was deliberate, clean or customer-visible. The outcome does show that Vertex was able to establish AS149513 as the accepted origin.

The move concentrates the public routing story around SyCloud. AS197547 remains registered in RIPE NCC but is not the current origin of the company's directly allocated /24. AS149513 originates a much larger mixed portfolio and appears at the exchanges. This may simplify policy and aggregate customer routes. It may also put more dependencies behind one autonomous system and one operational team.

Autonomous-system consolidation is not necessarily physical consolidation. AS149513 can span many routers and cities, while two ASNs can run on one device. The May change therefore tells us about routing authority, not about hardware. A proper migration record would identify the old and new edge locations, accepted route-origin states, customer notices, rollback conditions, observed convergence and any packet loss.

The same event exposes the limits of registry status. AS197547 is still assigned. A reader looking only at its RIPE record might assume it is active. A reader looking only at AS149513's ARIN registration might miss its routing history before September 2023. Current route collectors and historical observations are needed together to understand the operating state.

For resilience, the most important unanswered question is whether AS197547 remains a tested alternate or is now an administrative shell. If it retains independent routers, providers and accepted authorisations, it could offer a recovery option. If it was retired after consolidation, it adds no redundancy. Registration alone cannot decide.

Address space reveals a wholesale dependency surface

AS149513 originates blocks associated with several different resource holders. That can happen when a transit provider announces customer space, when customers authorise an upstream to originate on their behalf, when address space is leased, or when a network consolidates routes under one origin. The public data does not disclose the contract for each block, so ownership must not be inferred from origination.

This boundary is important for both risk and responsibility. Vertex directly controls routing policy at AS149513, but it may not control the registration, server, content or end user behind every prefix. A resource holder may control route-origin authorisation while Vertex controls the BGP announcement. A data-center customer may own the server while Vertex supplies transit. An upstream may carry the route while another company owns the metro circuit.

The AS-set names a group that includes AS197713, AS197547, AS151951, AS38047, AS153371 and AS401075, among others. Current routing classifications identify several of those as customers or downstreams. The exact membership differs between ARIN and APNIC copies of the set, and route-policy entities can become stale. The set should therefore be used for filtering context, not as a corporate organisation chart.

Observed downstreams make Vertex operationally consequential beyond its own /24. CAIDA counted four customers in its relationship inference. IPinfo listed five downstream networks. RIPEstat saw right-side neighbours including Shenzhen Lesuyun, Back Waves, FiberPower and Skyspark Hosting. These datasets disagree at the edges because commercial relationships are private and AS paths can be ambiguous. They agree that AS149513 is not merely a stub announcing one office prefix.

When a transit origin fails, the effect depends on customer design. A downstream with a second provider and portable address space may reroute. A single-homed customer can disappear globally. A customer whose prefix is originated directly by AS149513 may have no independent ASN visible in the path, making the dependency harder to see. A hosted service can remain addressed but fail at the server or facility layer.

Route-origin security adds another shared control. Hurricane Electric's early-July summary counted most originated routes as RPKI-valid but identified two invalid originated announcements in its view. Counts can change and need prefix-level confirmation before assigning blame. The existence of any invalid view is a reason for the operator and resource holders to reconcile route-origin authorisations, aggregates and more-specifics. A physically healthy network can lose reachability when large carriers reject an invalid route.

The customer-impact surface is therefore broader than a conventional local ISP's coverage map and narrower than the full internet. It consists of the prefixes and autonomous systems that depend on Vertex for origination, transit or exchange reachability at a given moment. That surface can change daily. A dated route inventory is more useful than a static claim of 1,000 possible prefixes.

Who is affected when the fabric breaks

A Hong Kong router failure would first affect sessions and routes terminating on that device. If equivalent sessions exist elsewhere and policy converges correctly, users may see a brief interruption or a longer path. If the router carries unique customer cross-connects, those customers can remain down after the internet-facing routes recover. The visible BGP graph cannot show those private last hops.

A facility outage has a wider boundary. It can remove routers, server racks, exchange cross-connects and carrier hand-offs together. Customers hosted in that building may lose both compute and network, while traffic for customers in another building reroutes. If management, authentication or monitoring systems also sit in the failed facility, repair can slow even when spare forwarding capacity exists.

A metro transport cut can create a deceptive failure. Exchange ports in several buildings may remain powered, but the wavelength joining them or linking them to the core can fail. Some prefixes stay visible through another edge while packet loss rises. If all long-haul traffic to Tokyo and Los Angeles crosses the same Hong Kong aggregation point, the network can look geographically distributed while behaving as one site.

A submarine-cable fault usually does not isolate Hong Kong because many systems and carriers serve the region. It can still raise latency and congestion when traffic shifts to surviving routes. The outcome depends on purchased capacity, route policy and destination. A network with many BGP neighbours but little spare transport can remain globally reachable while applications become slow or unstable.

A route-policy error can be global and immediate. An accidental withdrawal of the AS149513 routes would remove reachability from all otherwise healthy facilities. A leak of customer or full-table routes could overload links or send traffic through unintended paths. Incorrect RPKI state can cause selective reachability, with some providers accepting a route and others rejecting it. These failures are repaired by configuration and coordination, not fibre splicing.

People still determine restoration. Network engineers diagnose route changes; data-center technicians replace optics and power supplies; carrier staff repair fibre; exchange operators investigate shared fabric; resource holders update authorisations. If Vertex's public contact surface is limited, downstreams need contractual escalation channels that are not visible to outside observers. The absence of a public support page does not mean those channels do not exist, but it prevents independent assessment of their depth.

The affected end user may never know Vertex's name. A server customer buys from a downstream host, an application user reaches that server through a content domain, and the downstream buys transit from SyCloud. An outage appears as a slow website, failed game session, unreachable virtual machine or broken private service. This indirect dependency is why a relatively small transit network can matter beyond its legal footprint.

What a credible resilience account would show

Vertex can establish a much stronger position without disclosing sensitive router configurations. The first requirement is an accurate service description. It should say whether SyCloud sells IP transit, colocation connectivity, dedicated servers, virtual machines, address services, remote peering or some combination. It should identify the legal contracting party and the countries in which orders are accepted.

The second requirement is a metro-level topology. A public version could name Hong Kong, Tokyo and Los Angeles nodes; distinguish owned routers from remote ports; identify which facilities contain equipment; and disclose whether each metro has two router and power domains. Exact fibre paths need not be published, but independent-carrier and independent-entrance claims should be defined and auditable.

Third is capacity after failure. Nominal port speeds should be paired with normal peak utilisation and available capacity after the loss of the largest router, facility and inter-metro circuit. The metric should include packet loss and latency, not only interface load. A service that stays reachable at one-tenth of normal throughput has continuity but not full resilience.

Fourth is route hygiene. The operator should publish the current origin list, AS-set maintenance responsibility, route-origin authorisation coverage, filtering policy, customer-prefix validation and the outcome of the May 2026 ASN migration. The public record's two invalid-route count should be resolved at prefix level and dated, because aggregate views can lag.

Fifth is recovery operations. Each metro needs named 24-hour escalation, authorised remote hands, configured spares, configuration backups and tested out-of-band access. The company should state restoration targets for router, cross-connect, transit and customer-equipment failures, while distinguishing failures owned by a landlord or carrier. A public status page should be hosted outside the same network it reports on.

Sixth is customer portability. Downstreams should know whether they can announce their space through another provider, whether Vertex originates their prefixes, how quickly route objects and authorisations can change, and what happens to addressing when a contract ends. This is both a resilience and an ownership question.

Evidence for these controls would move the network grade from Medium toward Strong. Evidence of shared routers, one Hong Kong core, oversubscribed backup paths, stale authorisations or unavailable support would move it lower. The public record currently supports neither extreme.

A corrected assessment

Vertex Connectivity LLC has enough current evidence to escape the "thin footprint" label at the network layer. AS149513 is active, dual-stack and globally visible. It appears on five exchange fabrics, lists ten facilities and has several large external paths. Its directly allocated IPv4 block completed a visible origin change in May 2026. Those are concrete signs of operation.

The evidence does not support the original physical model. There is no verified last mile, fixed-wireless system, fibre access plant, tower estate, household coverage area or customer-premises install base. There is no basis for discussing pole independence, local density economics or a field crew driving to subscribers. Keeping those claims would turn a name-based guess into a false company profile.

The supported model is a small but internationally connected hosting and transit network operating as SyCloud, with its strongest visible footprint in Hong Kong and additional interconnection in Tokyo and Los Angeles. It depends on third-party data centers, exchange fabrics, cross-connects, metro and long-haul transport, external carriers, remote hands and route policy. Its likely customers include hosting or network operators rather than a documented local population.

The model remains incomplete. PeeringDB's 200-300 Gbps traffic band and port speeds are self-reported. The public website is not addressable at its usual endpoints. Service terms, customer count, staffing, ownership, private capacity, physical route diversity, power design and recovery records are absent. Route collectors can show that packets have a path to the edge; they cannot show whether the service behind that edge is healthy or contractually protected.

The final operating-status judgment is therefore active network, opaque service and unverified physical resilience. The network evidence grade is Medium. Strong route and interconnection evidence is offset by weak commercial and infrastructure disclosure. Vertex's most important bill is not a local broadband invoice. It is the recurring cost of keeping ports, transport, facilities and people independent enough that a multi-city network does not collapse back into one Hong Kong failure domain.