A São Paulo power transfer tests what Cloudflare's Latin American anycast map cannot promise

Summary

• Cloudflare discloses a wide Latin American city footprint and 500 Tbps of global external interconnection, but it does not publish the server count, contracted power, live port headroom or physically diverse routes available at each Latin American site.
• Public records establish a Costa Rican company, Costa Rican address resources and a San José deployment associated with NIC.CR, yet they do not establish that the Costa Rican company owns or contracts every regional rack, circuit or customer relationship carrying the Cloudflare name.
• Anycast can move reachability away from a failed location, but successful recovery still depends on spare compute and network capacity, independent facility power, surviving metro fibre, functioning cross-connects and people authorised to restore the affected equipment.

The transfer switch is where the map stops

Consider a carrier-neutral facility in the São Paulo metropolitan area during a planned electrical transfer. The utility feed is removed from service, uninterruptible power carries the load for the interval between feeds, and generators or a second utility path are expected to take over. A technician watches the rack power distribution and the optical cross-connects while network engineers watch the routes. This is a stress case, not a report of a particular Cloudflare accident. It is useful because it strips away the visual ease of a global edge map.

At the instant of transfer, the relevant questions are concrete: which cabinets remained energised, which routers retained light, which peers stayed reachable, and how much work could be accepted somewhere else?

Cloudflare's own operational notices reveal the intended network response. During scheduled work in its GRU location on 3 July 2026, the company warned that traffic might be rerouted, end users could see a slight increase in latency, and private or customer interconnect interfaces in that data centre might become temporarily unavailable. The notice later marked the work complete. That sequence is visible in the GRU maintenance record. It is narrow evidence: it shows an announced maintenance window and the expected behaviour of interfaces, not the identity of a building, the reason for the work, a measured traffic shift or the amount of reserve capacity used elsewhere.

The broader public status page separates Latin American locations such as San José and São Paulo into named components and gives each a current condition. That is valuable operational visibility, but a green component is a snapshot. It does not disclose whether the component represents one room or several, whether two rooms share a substation, or whether a nominally available neighbour could accept a sudden regional load. Nor does it identify which legal company bought the power, leased the rack or signed the cross-connect order.

The normal intuition is that anycast solves the location problem. Cloudflare's explanation of anycast says that the same address can be served from multiple locations and that taking a data centre offline can cause traffic to flow to a nearby one. That describes reachability. It does not manufacture watts, server cycles or uncongested ports at the receiving location. If São Paulo withdraws routes, users may land in Rio de Janeiro, Curitiba, Porto Alegre, Buenos Aires, Santiago, Bogotá, Miami or another available location depending on the routes their access providers select. Each alternative adds its own facility, carrier and capacity conditions.

The power transfer therefore tests two systems at once. The first is local: utility feeds, switchgear, batteries, generators, cooling, rack distribution, routers and cross-connects must remain within tolerances. The second is regional: route changes must propagate cleanly and the destinations that gain traffic must have usable headroom. A city map represents neither system at that resolution. It shows service geography, not the electrical and commercial dependencies that determine whether failover is graceful.

The gap matters because customers experience the result as one service even when the physical responsibility is split among Cloudflare, facility operators, carriers, exchanges and on-site contractors.

A city dot is not a failure domain

Cloudflare's current network page presents a large Latin American footprint, with dozens of cities across Brazil and locations from San José to Bogotá, Lima, Santiago, Buenos Aires and beyond. The page also says every service runs in every data centre. Those statements establish the intended breadth of the edge and the common-service design. They do not establish that every city contains the same number or generation of servers, the same number of upstreams, the same ability to take traffic from another city, or the same protection from a local power event.

Cloudflare has itself explained why the city is too coarse a unit. In a 2019 account of scaling its global network, the company said a city could contain as many as five distinct deployments. It also described capacity planning by address, not merely by city, and described the use of vendors and on-site remote hands to install servers and cable them. The disclosure was historical and global; it is not a current census of Latin America. Its continuing analytical value is the distinction it makes: one metro label can conceal multiple physical addresses, while a small-city deployment can be embedded inside an internet service provider rather than a large neutral campus.

The company's latest annual disclosure supplies the other half of the boundary. Cloudflare's 2025 Form 10-K says its network was hosted in colocation and internet-service-provider partner facilities in more than 330 cities and more than 125 countries at the end of 2025. It says Cloudflare has electronic and, to a lesser extent, physical access to equipment hosted by third parties, but does not control the operation of those facilities. The same filing identifies power loss, carrier decisions, facility closures, human error and limits on bandwidth as risks. Those are not theoretical decorations around a dot; they are the operating boundary of the dot.

Breadth also comes in different physical forms. A 2023 expansion account said Cloudflare had reached more than 300 cities and described a new site in Campos dos Goytacazes, Brazil, interconnected with a regional provider serving more than 100 local internet service providers. The company reported that latency measurements improved materially after the site opened. That city expansion account supports the presence of a partner-led edge close to users. It does not disclose rack power, server quantity, port utilisation or the route that would carry load if the partner site failed.

A useful failure domain must be drawn around shared dependencies. Two deployments at different street addresses may still depend on the same utility substation, carrier duct, exchange fabric, long-haul exit or local support vendor. Conversely, two cabinets in one large campus may have meaningfully separate power trains and diverse fibre entrances. Public city lists do not resolve either case. Even a named facility does not prove that a particular customer's two circuits terminate on separate devices or that reserved capacity exists behind each one.

This is why a count of cities is not a count of independent recovery choices. It is a measure of geographic reach. To convert it into a resilience claim, a reader would need the number of active sites per metro, their power and fibre correlation, the workloads enabled at each, the normal and emergency utilisation of each port, and the policy for withdrawing or restoring routes. None of those items can be inferred merely because São Paulo, San José and Bogotá appear on the same map.

The Costa Rican company is a boundary, not a regional asset label

CloudFlare Latin America S.R.L is a real Costa Rican legal presence, not a geographic nickname. Costa Rica's official gazette recorded a January 2026 corporate action by “Cloudflare Latin America S.R.L.” and gave legal-person number 3-102-651761. The notice concerned its official electronic address and resident representation, not network assets, but the gazette entry is recent public evidence that the company exists within Costa Rica's corporate system.

Internet-number records provide a separate tie. LACNIC's public registration for 190.93.240.0/20 names CloudFlare Latin America S.R.L as the registrant and gives a San José-area address, while operational contacts point to Cloudflare network operations in San Francisco. This supports a relationship between the Costa Rican company and address resources used under the wider Cloudflare operation. It does not prove that every address is served only in Costa Rica. Anycast deliberately allows the same service addresses to be announced from multiple places, and an address registration is not a rack inventory or title document.

The customer-contract surface points in a different direction. Cloudflare's standard Enterprise Subscription Agreement states that the public agreement is between the customer and Cloudflare, Inc., a Delaware company. It also allows affiliate use and separate affiliate order forms. The correct conclusion is limited: the public standard terms do not assign ordinary enterprise subscriptions to the Costa Rican company. They do not rule out a different order form, local tax arrangement, property lease, employment contract, carrier agreement or affiliate transaction. Those documents are not public in the material reviewed here.

The same caution applies across Latin America. A Cloudflare-branded rack in Brazil could be owned by Cloudflare, Inc., another affiliate, a service partner or a hosting counterparty under terms not visible to outsiders. The Costa Rican company may hold particular number resources or local obligations without being the contracting party for a São Paulo room. Conversely, the absence of its name from a facility page would not show that it has no financial or operational role. Public facility and routing records normally identify the network or brand, not the internal allocation of rights among affiliates.

This boundary matters during failure. The party that can ask a carrier to test light levels, authorise a remote-hands visit, approve emergency spend or enforce a service commitment may not be the same party named in a public IP record. Regulatory demands may also attach to the local company even when operational decisions are taken elsewhere. Without contracts, board records or explicit affiliate disclosures, attributing regional control to CloudFlare Latin America S.R.L would go beyond the evidence.

The most defensible description is therefore layered. Cloudflare, Inc. reports the consolidated global network and its third-party facility dependencies. AS13335 is the global routing identity. CloudFlare Latin America S.R.L is a Costa Rican company associated with LACNIC resources and a current Costa Rican legal record. NIC.CR was named as the partner for the first San José deployment. These layers plainly relate to one service, but they are not interchangeable. A regional edge story that collapses them into “the Costa Rican company operates Latin America” would turn association into ownership and ownership into control without public proof.

San José proves presence, not control

Cloudflare announced its first Costa Rican deployment in June 2021. Its San José expansion account said the location was established with NIC.CR, run by the Academia Nacional de Ciencias. This is direct company evidence for a deployed presence and a named local partner at that time. The current network map and status component indicate that San José remains represented in the live footprint. Neither disclosure names the building, server count, power allocation, carrier list, replacement-part stock or contractual owner of the equipment.

NIC Costa Rica describes CRIX as a neutral internet exchange that lets local networks exchange traffic at a common point inside the country rather than relying on international links. That NIC.CR infrastructure description establishes why a San José edge can matter: local peering can keep some Costa Rican traffic local, lower dependency on international transit for that exchange, and reduce distance to cached or processed content. It does not establish Cloudflare's current port size or whether every Costa Rican access provider reaches Cloudflare through CRIX.

Cloudflare's current self-reported PeeringDB network record identifies AS13335 as a global anycast network and lists its public peering and facility relationships. The record includes an operational CRIX connection and reports a 200 Gbps exchange port for that entry at the time examined. PeeringDB is important operational evidence because Cloudflare says it uses the service for peering provisioning. Yet its values remain self-reported and mutable. A listed port speed is the nominal interface rate, not observed traffic, committed throughput, spare capacity or proof of a second physically diverse port.

This produces a precise but modest San José picture. There is a city presence announced with NIC.CR, a current status component, a public exchange connection and address resources registered to the Costa Rican company. There is no public facility address in those sources. There is no disclosed count of independent deployments inside the metro. There is no power single-line drawing, no generator autonomy figure tied to Cloudflare's cabinets, and no route-diversity statement showing separate fibre entrances or upstream paths.

The distinction between locality and control is especially important here. CRIX can localise traffic between connected networks, but the exchange fabric itself becomes one element of the service path. A cross-connect from Cloudflare's router to the exchange can fail while the servers remain powered. The edge can also stay reachable through transit while a local peering session is down, at the cost of a longer path. A facility can remain operational while a carrier suffers a metro cut. A city component can therefore be degraded in several ways that a binary city dot cannot describe.

San José also cannot stand in for the regional network. Even if its local traffic is small enough for one exchange port and one deployment, that says nothing about the ability to absorb traffic from Guatemala, Panama, northern South America or Brazil. The absence of a published server and utilisation series prevents a comparison between installed hardware and emergency headroom. The visible 200 Gbps exchange interface should not be added to global capacity figures as if it were an independently usable reserve; it is one interface in a larger set of transit, private and public connections, and its live demand is not disclosed.

What San José proves is significant: Cloudflare moved service closer to Costa Rican users and established a local interconnection relationship. What it leaves unanswered is the question in this article's title. When a larger Latin American metro loses power or withdraws routes, the public record does not show how much traffic San José could take, which applications it could process under customer locality settings, or which company would direct the physical recovery.

São Paulo is several rooms, ports and commercial dependencies

São Paulo is the strongest public illustration of why one city label can conceal several distinct operating surfaces. Cloudflare's PeeringDB record lists the network at Equinix SP2 and SP4 in Barueri, at Ascenty SPO02 and SPO03 in Osasco, and at Elea SPO1 in São Paulo. This is not necessarily a complete live inventory, and a facility listing does not reveal how much equipment is active there. It does show that the metro cannot responsibly be treated as a single room.

Cloudflare's May 2026 customer-interconnect location list makes the multiplicity even more explicit. It names several São Paulo facilities for customer interconnection, including Equinix SP2 and SP4, Ascenty SPO02 and SPO03, and Elea SPO1. The document is a service-location list, not a map of the company's internal edge or backbone. It shows where a customer connection can terminate; it does not show that every listed site has identical edge compute, that connections in two buildings use separate carrier routes, or that every location can substitute for every other.

Facility disclosures add physical context without closing the Cloudflare-specific gap. Equinix says SP4 has N+1 UPS and generator redundancy, at least 30 hours of generator autonomy at full load, N+1 cooling and smart-hands services. Those are operator specifications for the building. They do not reveal which power train feeds Cloudflare, the load of its cabinets, the maintenance state of a particular component, the amount of fuel present on a given day or whether a Cloudflare circuit crosses a shared point before entering the facility.

The GRU maintenance notice supplies a live behavioural clue. It treated the São Paulo location as a component from which traffic and private interfaces could fail over. It did not identify which of the several buildings was involved. “GRU” may represent an operational grouping larger than one facility, or the notice may deliberately abstract facility detail. Either way, the component label should not be read as a physical address.

Metro diversity only helps when dependencies are genuinely independent. SP2 and SP4 may be separate facilities, but the decisive paths include utility supply, generator and UPS trains, meet-me rooms, ducts, carrier rings, exchange fabrics and the backbone exits connecting the metro to other cities. Two customer interconnects ordered in two buildings can still converge on one carrier route. Two Cloudflare deployments can still share change authority or a regional control dependency. None of the public sources maps these correlations.

Commercial concentration adds another layer. The 10-K says a significant number of important colocation agreements are with one unnamed company. Equinix is visible in the public São Paulo facility list, but the filing does not identify the concentrated provider, and it would be unsupported to assume the name. The relevant point is that physical distribution across cities or rooms does not automatically remove contractual concentration. A vendor dispute, support failure or adverse pricing change can affect expansion and restoration choices even when the network remains technically routable.

São Paulo is therefore best described as a metro with several publicly visible interconnection and facility options, not as a quantified pool of interchangeable capacity. The evidence supports more than a dot but less than a resilience diagram. It shows rooms and services that could participate in diversity; it does not prove the independence, allocation or emergency capacity required for them to do so.

Peering localises traffic but can concentrate the metro

Cloudflare's December 2025 peering policy says AS13335 spans more than 335 cities, asks peers to establish sessions in all mutual locations and supports private interconnections in multiples of 100 Gbps for networks above a traffic threshold. It also recommends using all available addresses when more than one is present at an exchange. Those practices can improve path diversity and make it easier to move traffic among ports. They remain policy conditions, not proof that a given Latin American peer has ordered diverse cross-connects or kept sufficient unused capacity.

The historical build-out shows how different the local arrangements can be. In Medellín, Cloudflare said its 2014 launch relied on Internexa and that local service was carried over the partner's terrestrial network. The Medellín announcement described an important reach advantage, but also makes the dependency visible: traffic locality was connected to one partner's backbone. The present network may be broader; the old account cannot be treated as a current topology.

In Quito, the company said its 2017 site was made possible through the NAP.EC exchange and that additional local peers could shift traffic that had previously been served from Miami. The Quito account demonstrates the value of a local exchange and the prior dependence on an overseas hub. Again, it does not show today's racks, ports or fallback destinations. It also illustrates that “local” is relational: a deployment is local only for networks that can reach it through acceptable routes.

Bogotá began with another disclosed physical arrangement. Cloudflare's 2018 Bogotá account said the deployment was in a Tier III facility in the city's free-trade zone. Current public records list Cloudflare at Equinix BG2, but the historical description does not name that site, so the two records cannot be joined into an unbroken facility history without more evidence. What can be said is that Bogotá has had a disclosed physical presence and now has a current facility listing.

The long-distance path between these metros is equally important. Cloudflare says its backbone uses owned dark fibre or leased dense-wavelength services within and between cities, purchased from global carrier partners. The company's backbone description explicitly calls its illustrated map a simplification that does not show every path. That caution should govern any reading of lines between Latin American dots. A drawn line does not identify a carrier, landing station, conduit, wavelength, protection route or available bandwidth.

Peering can reduce transit cost and avoid sending local traffic to Miami, but it can also concentrate traffic into the facilities where the exchange is available. If a country's local internet exchange and a major edge deployment share a building or metro duct, local performance improves during normal operation while correlated physical risk may remain. Multiple bilateral sessions on one switch fabric do not protect against a fabric-wide or building-wide event. Multiple carriers in one meet-me room do not prove diverse entrances.

The desired evidence is path-specific. For each major metro, a resilience assessment would identify the exchange ports, private interconnects and transit links; whether their cross-connects land on separate routers; whether the carriers exit through separate ducts; and which regional sites are allowed to announce the affected routes after withdrawal. Public records reveal pieces of that picture. They do not reveal the complete chain, so claims of seamless regional failover remain conditional.

Anycast reroutes reachability, not electricity or spare headroom

Anycast is powerful because it separates a service address from one physical destination. When a location stops announcing a route, upstream networks can select another announcement. But the selected destination is the best path according to routing policy, not necessarily the geographically nearest city or the location with the largest unused server pool. Cloudflare's geographic routing guidance acknowledges that requests may not reach the closest physical data centre and says reliability can take priority over locality.

There are three distinct recovery steps. First, the impaired location must be removed from the incoming path, either through route withdrawal, traffic engineering or upstream change. Second, the internet must converge on alternative announcements. Third, the receiving locations must accept the added connections without exhausting compute, memory, cache, router, cross-connect or transit resources. The first two are routing actions. The third is a capacity condition.

Within a surviving location, Cloudflare uses another layer of distribution. Its account of Unimog explains how connections are spread among servers, how unhealthy servers are removed and why load must be adjusted for machines of different performance. This can route around a failed server or overloaded host inside a data centre. It cannot help if the entire room loses power, the edge router goes dark or all external paths are severed. In that case, the regional anycast layer must carry the recovery.

Private interconnect customers have an additional dependency. Cloudflare's current interconnect operational guidance says a customer deployment must tolerate the unplanned loss of any single circuit and that failover between redundant circuits should be automatic. It also notes that maintenance is not coordinated between different locations. This assigns part of resilience to customer design: a customer with one physical interconnect in GRU may lose that direct path even if Cloudflare's public edge remains available elsewhere.

The difference matters for affected services. A public website connection can often follow another anycast route without customer action, although latency and cache behaviour may change. A private network interconnect may require a second circuit, suitable route policy and enough capacity at its alternate termination. A long-lived connection can break even when a fresh connection succeeds elsewhere. A regionalised application may be restricted to a subset of locations. A customer's origin path can also remain impaired after the edge moves, particularly if the origin is connected through the same metro.

Anycast recovery is thus a transfer of demand, not the disappearance of demand. If GRU ordinarily processes a large volume and withdraws, some combination of other sites must process it. The public record does not disclose the normal GRU load, the share that can be served from cache, the product mix, the destination distribution or the utilisation of the receiving sites. The phrase “traffic might be rerouted” is accurate but incomplete; it describes the movement without quantifying the landing.

The credible resilience claim is conditional: reachability can move if routes withdraw cleanly, and service can continue if alternative paths and locations have the necessary resources and are permitted to handle the work. Electricity remains local. Spare headroom remains finite. An internet route can point around a dark building, but it cannot make the alternative building ready.

Installed capacity is not usable failover capacity

Cloudflare announced in April 2026 that it had crossed 500 Tbps of external interconnection. Crucially, the company defined the number. Its 500 Tbps account says the figure is the sum of provisioned ports facing transit providers, private peers, internet exchanges and customer interconnects across more than 330 cities. It also says the number is not peak traffic and that the difference supports denial-of-service absorption.

That is a meaningful global scale measure. It is not a Latin American capacity table. Summing port rates counts installed interfaces wherever they sit, even though some ports cannot substitute for others. A customer interconnect in Bogotá cannot automatically carry public cache traffic displaced from São Paulo. A port connected to one peer reaches that peer's traffic, not every user. Two 100 Gbps links on the same router or fibre route are less independent than two links in separate facilities. Port capacity also says nothing directly about server cycles, storage, cache warmth or electrical power behind the routers.

Cloudflare's peering policy reinforces the unit problem. It supports Nx100G private connections and sets traffic thresholds for requesting them, but does not publish current utilisation. PeeringDB marks the network's overall traffic level as undisclosed. The resulting public evidence can show that large interfaces exist and name some locations; it cannot show how many gigabits remain safely usable during a regional event.

The financial disclosure is similarly aggregate. The 10-K reports $179.357 million in non-cancellable bandwidth and other colocation commitments at the end of 2025, spread over future periods. That proves the company purchases long-term network capacity and space at significant scale. It cannot be allocated to Latin America from the filing, and expenditure is not throughput. A contract can reserve space that is not yet in service, cover a fixed term rather than an emergency reserve, or include products whose capacity is not interchangeable.

Facility figures must be kept in their own category. SP4's N+1 power arrangement and stated generator autonomy describe the building. Equinix says Bogotá BG2 has N+1 UPS and generator redundancy, 72 hours of generator autonomy and 24-hour support. Cirion's Lima LIM1 specification describes 2N power, N+1 cooling and more than 2,200 square metres of raised-floor colocation. Current public records associate Cloudflare with these facilities or customer-interconnect locations, but the facility ratings are not Cloudflare allocations. They say what the operator designed, not how much power or floor space Cloudflare bought.

Usable failover capacity is narrower than every one of these installed measures. It is the share of alternative compute, power and network resources that is healthy, reachable, contractually available, compatible with the affected service and unconsumed at the moment of failure. It must allow for traffic growth during convergence, cache misses, attack load and the possibility that a second dependency is degraded. A prudent reserve is therefore not simply “unused port rate.”

No public source reviewed here gives that number by Latin American metro. That absence prevents a quantitative claim that São Paulo traffic could be fully absorbed within the region. The global 500 Tbps figure makes such absorption plausible for many ordinary events, but plausibility is not measurement. Until per-site utilisation, service eligibility and correlated failure limits are published, the correct conclusion is that installed scale is strong while regional usable headroom remains undisclosed.

Recovery passes through remote hands, carriers and change authority

When a room loses power, route withdrawal is only the beginning. Someone must determine whether utility feeds, switchgear, UPS, generators, cooling and rack distribution are stable. Someone must inspect router and server power, verify optical light, replace failed components, restore circuits and sequence equipment back into service. In a third-party facility, those tasks cross organisational boundaries.

Cloudflare's November 2023 Oregon power-failure account is outside Latin America and concerned core services rather than a Latin American edge site. It is still a valuable disclosed example of the physical recovery chain. The facility lost utility and generator power after a ground fault; batteries depleted; access and staffing complicated generator restart; Cloudflare learned of trouble when routers went offline; circuit breakers then had to be replaced; and servers were brought back in a controlled sequence. The company clearly separated confirmed facts from informed speculation where the facility operator had not supplied answers.

The same facility failed again in March 2024. Cloudflare's second power-event account said prior changes improved the response and reduced the impact. The comparison shows that recovery quality depends on preparation, tested dependencies and clear activation criteria, not just redundant equipment on a facility specification sheet.

For Latin American edge sites, the 10-K says third-party contractors may install and maintain hardware abroad and that Cloudflare does not control third-party facility operations. Public facility support information helps identify one human dependency. Equinix's colocation support availability lists 24-hour on-site operational coverage for Bogotá BG2, while coverage differs at other sites. That does not reveal Cloudflare's service entitlement, response target, spare inventory or whether a technician is authorised to touch a particular device. It shows why staffing belongs in the physical assessment.

Carrier recovery has its own chain. A cross-connect failure requires coordination between Cloudflare, the facility and the peer or carrier. Low optical light can result from a dirty connector, damaged fibre, failed optic or longer-path issue. Restoring one side without confirming the other can leave the session down. For a customer interconnect, the customer must also have automatic failover and sufficient alternate capacity. For an exchange failure, sessions may need to move to private or transit paths.

Change authority can become the slowest dependency. The person who sees a route problem may not be able to approve facility access. The local facility may require a letter of authorisation before moving a cross-connect. A contractor may need a dispatch number. A carrier may insist on tests at a demarcation point before escalating. An affiliate may hold the contract while a global operations team directs the repair. None of these steps is visible in a status colour.

The safe restoration path is also slower than simply applying power. A facility returning after an unstable event may need circuits energised in stages to avoid inrush load. Network devices should be checked before servers attract traffic. Health and capacity need to be confirmed before routes return, otherwise demand can oscillate between sites or overload a partially restored room. Cache and long-lived connection behaviour may take additional time to normalise.

Public evidence supports Cloudflare's ability to learn from severe power events and operate a global response. It does not disclose Latin American site runbooks, local spares, recovery-time targets or authority maps. Those omissions do not prove weakness. They mean that the human and contractual part of resilience cannot be independently verified from the city footprint.

Who feels the failure first

The first affected population depends on which layer fails. If one server fails but the router and room remain healthy, local load distribution can remove it with little visible effect. If one exchange port fails, users of peers that relied on that port may take longer paths while users arriving through other carriers remain local. If a whole site withdraws, many access networks may shift together. If a metro loses several correlated paths, a much larger region can be sent to more distant cities.

End users notice latency, connection resets, lower throughput or errors. The pattern will not be uniform across a country. An internet service provider with a direct session in San José can follow a different path from one buying upstream transit. Mobile and fixed networks can make different routing choices. A cache hit may complete locally while an uncached request still depends on an origin in the failed metro. The status of “San José” or “São Paulo” therefore does not translate into one national experience.

Cloudflare customers using private interconnects face a more explicit boundary. The GRU notice told them to expect interfaces to become unavailable and to arrange failover elsewhere. If their alternative circuit is in the same metro or uses the same carrier path, nominal redundancy may not help. If it terminates in another city, it must be sized for the transferred demand and its routing must activate without a manual delay. Public-edge continuity does not by itself restore a private path.

Data-locality choices narrow the receiving set. Cloudflare's Regional Services description says encrypted connections can be accepted globally while HTTPS decryption and application-level processing occur only in the selected region. This means a location outside the selected set may absorb the network connection but cannot necessarily perform all of the work. Failover capacity must be counted within the permitted processing region, not across every dot on the world map.

The current region-support table lists Brazil as a managed Regional Services region. It does not list a single managed region covering all of Latin America, although custom configurations may be available for some options. A Brazilian locality commitment can therefore make the number and distribution of healthy Brazilian sites especially important. Capacity in Miami, Bogotá or San José may be physically reachable but ineligible for decryption under that setting. The product configuration of each customer matters.

Public-sector services, banks, retailers, health providers, media, software services and small websites can all sit behind the same edge, but their failure costs differ. A short delay on a static page is not the same as loss of a payment connection, employee access path or public information service. Customers with a second provider or bypass route may recover independently; customers that depend exclusively on Cloudflare need Cloudflare's edge and their own origins to stay connected. Cloudflare's 10-K acknowledges that customers can lose access to their networks or the internet until service returns or they invoke a bypass.

The first users to feel a failure are therefore not necessarily the closest to the dark room. They are the users whose access provider, product, locality rule, private circuit and origin path leave the fewest alternatives. That distribution cannot be derived from geography alone. It requires traffic and customer configuration data that are not public.

The evidence still missing from a credible resilience claim

The public evidence is enough to establish a substantial Latin American operating surface. Cloudflare lists a broad city footprint. It reports a San José deployment with NIC.CR and an active status component there. Its PeeringDB record shows present exchange and facility relationships. Customer-interconnect material identifies named facilities from São Paulo to Bogotá and Lima. Facility operators publish power, cooling and support characteristics. Cloudflare reports global external interconnection at 500 Tbps and openly describes third-party facility, carrier and power risks.

It is not enough to prove that the region can absorb the loss of a major metro without material impact. The missing evidence begins with a dated inventory: active facilities per city, the services enabled at each, server generations, usable compute, contracted rack power and external port capacity. The next need is utilisation: normal and high-percentile load, reserve policy, attack allowance and the tested maximum transfer from each major failure domain. Global totals cannot answer those local questions.

Physical independence also needs proof. For each pair of nominally diverse sites, a useful disclosure would identify separate utility supply, UPS and generator trains, fibre entrances, meet-me rooms, exchange fabrics, carrier routes and long-haul exits. It would state where two “diverse” circuits converge. It would distinguish a separate building from a separate metro and a separate metro from a separate international landing path. The current backbone illustration expressly does not show all routes, and facility marketing does not map customer-specific circuits.

The legal and commercial boundary remains incomplete. The Costa Rican company's recent legal record and LACNIC registration are strong evidence of local presence, but there is no public schedule assigning regional facilities, carrier contracts, equipment ownership or emergency authority among Cloudflare affiliates. The standard customer agreement names the Delaware parent. A credible account should therefore name the contracting entity only where a public document does so and avoid treating the Costa Rican name as a blanket regional operator label.

Recovery evidence would include the alert path from facility to Cloudflare, remote-hands response commitments, spare-part location, carrier escalation, route-withdrawal thresholds, restart order and proof of full-site exercises. The Oregon incidents show why these details matter, but they do not establish Latin American performance. A facility's N+1 or 2N rating is an input, not an outcome. Testing should include loss of the whole room, loss of a metro carrier path and loss of a permitted locality region, not only individual devices.

Customer impact needs its own measurement. Public reporting could show, without exposing customers, how much traffic moved, where it landed, how latency changed, whether private interconnects failed over, whether regionalised services remained within their permitted locations and how long caches and long-lived sessions took to stabilise. The GRU maintenance notice states the expected direction of travel but publishes none of those results.

None of the missing items proves that Cloudflare lacks resilience. Secrecy around exact sites and capacity can itself protect security and bargaining power. The point is narrower: the public map and global capacity number cannot support a quantitative regional failover promise on their own. What can be defended is a conditional chain. Cloudflare has many locations and multiple forms of interconnection; anycast and local load distribution can move work; third-party facilities and carriers provide the physical platform; and successful recovery depends on independent power, routes, capacity and human action that are only partly visible.

Return, finally, to the São Paulo transfer switch. If the second feed holds, routers retain light and the facility stays cool, users may never know it moved. If the room goes dark, routes can leave. Whether the service survives gracefully is decided in the receiving rooms: their spare watts, server cycles, ports, permitted workloads and working paths. Those are the quantities a city dot hides. Until they are disclosed or independently measured, the honest reading of Cloudflare's Latin American edge is not “the map heals itself,” but “the map shows where a carefully maintained physical chain is expected to answer.”