Semarang Data Center turns a regional facility claim into a power and backhaul test

Summary

• PT Semarang Data Center is best evidenced today as the operator of a compact Semarang interconnection site and PANDA-IX, not as a disclosed large data hall. Its public commercial offer is for 1U, 2U and 4U network-device colocation, and its listed facility is room 214 on the second floor of Hotel Pandanaran.
• PANDA-IX has current operating evidence: PeeringDB lists a single Semarang facility, 14 peers, 15 connections and 138G of nominal port capacity, while the public route-server looking glass reported 362 days of uptime on 13 July 2026 with multiple established IPv4 and IPv6 BGP sessions.
• The facility evidence does not yet prove resilient usable capacity. Public records do not disclose total design power, installed IT load, rack count, UPS topology, generator runtime, fuel arrangements, cooling redundancy, separate fibre entrances, dual utility feeds, carrier handoff paths, or customer failover tests.
• AS154034 has no current global RIS visibility, but that is not by itself an outage verdict. A route-server ASN can support a local exchange fabric without originating globally reachable prefixes; the right test is whether local sessions, customer paths and external reachability survive specific failures.

A compact room has to carry a city claim

Semarang Data Center's public story begins with a useful regional idea. Central Java networks should not have to send every local exchange of traffic through Jakarta or another larger hub when a local handoff is possible. A small interconnection site in Semarang can shorten paths between nearby operators, reduce avoidable transit use, and give regional providers a place to peer without committing to a full cabinet in a distant data centre. That is a practical claim, and the public evidence shows it has moved beyond a brochure. PANDA-IX has a listed exchange, a live route-server view and a set of network participants.

The same evidence also narrows the claim. PT Semarang Data Center says on its own website that it was established in February 2025 and operates in the data-centre colocation industry for Central Java. The commercial offer is small and specific: 1U, 2U and 4U packages, each described for network devices. The company also presents Panda Internet Exchange, or PANDA-IX, as the place where customers can exchange traffic. That combination points to an interconnection-led facility: routers, switches, cross-connects and local BGP sessions are the public centre of gravity.

The physical address makes the infrastructure question sharper. The operator's site gives the data-centre location as Hotel Pandanaran, second floor, Jalan Pandanaran No.58 in Semarang. The PeeringDB facility entry is narrower: SDCT Data Center, room 214, second floor, Hotel Pandanaran, with 13 listed networks, one local exchange, 400 VAC service and no disclosed diverse serving substations. The hotel's own site confirms the Pandanaran hotel property and address. This is not a remote campus with a public utility yard and a published data-centre campus plan. It is, on the public record, a room-scale infrastructure node inside an operating hospitality building.

That does not make the site unserious. Many useful internet facilities begin as small rooms where the right networks meet. A modest exchange can be more important to a city than a larger but distant campus if it gives local operators a working place to hand off traffic. The issue is not scale. The issue is evidence. A customer buying one rack unit at a regional exchange is buying a chain of dependencies: building power, distribution, energy storage, generator, fuel, cooling, fire detection, suppression, access control, fibre entry, switch fabric, route servers, upstream reachability and human response.

The shortest visible link in that chain is the rack space. The most important links are usually the ones outside the rack.

The article's central test is therefore not whether Semarang Data Center can call itself a data centre. The test is whether the public record lets a network operator distinguish announced service, installed equipment, lit exchange sessions, powered facility systems, operational exchange capacity and usable capacity under failure. At the moment, those states are uneven. The exchange surface is visible. The building-systems surface is mostly not.

The company identity is clearer than the facility boundary

The company itself is not hard to identify. The APNIC records for AS154034, 165.101.31.0/24 and 2001:df5:c140::/48 tie the autonomous system and address resources to PT Semarang Data Center. APNIC explains that Whois records identify the organisations responsible for address and ASN resources; they are not load tests, power tests or traffic meters. They establish responsibility for number resources, not the endurance of a room in a building.

The address evidence separates the legal and physical surfaces. The operator's site gives PT Semarang Data Center's contact address as Jalan Sumbawa II No.3, while the data-centre address is Hotel Pandanaran, second floor. APJII membership and corporate-directory mirrors also point to the Jalan Sumbawa office context. PeeringDB and the operator site point to Hotel Pandanaran for the facility. These two addresses should not be collapsed into one asset. The office helps confirm the corporate identity. The hotel room is the infrastructure site readers need to understand.

That distinction matters because control is different at each boundary. PT Semarang Data Center can control the exchange policy, route-server configuration, customer communication and the equipment it owns or manages. The hotel owner or building operator controls at least some property systems. PLN controls the public electricity supply outside the building. Fibre providers control their off-site routes, ducts, poles, manholes and handoff equipment. Local authorities control building, fire, road and emergency conditions around the site. A regional exchange is only as resilient as the weakest common dependency among those owners.

The public record does not yet show whether SDCT owns room 214, leases it directly, uses managed building services, or shares electrical and cooling systems with the hotel. It does not show who owns switchgear, transfer equipment, UPS systems, generator capacity, fire suppression, cooling plant, fibre risers or controlled access points. It also does not show who has authority to enter the room during a hotel incident or a citywide emergency. Those are not bureaucratic questions.

They determine who can authorise maintenance, who can prioritise loads during a generator event, who can refuel, who can isolate a fire system, who can reopen access after an evacuation and who pays when a shared building failure interrupts network service.

The best public conclusion is therefore bounded. PT Semarang Data Center is the responsible company for the named exchange and number resources. The public facility boundary is a second-floor room in Hotel Pandanaran. The ownership and operating boundary between PT Semarang Data Center, the hotel, utility suppliers and network providers remains only partly visible.

PANDA-IX is the strongest operating evidence

The strongest current evidence sits on the peering LAN. The PeeringDB exchange page lists PANDA-IX in Semarang with 14 peers, 15 connections, 13 open peers, 138G of total nominal capacity and one local facility, SDCT Data Center. It records the IPv4 LAN as 165.101.31.0/24 and the IPv6 LAN as 2001:df5:c140::/48. The exchange notes also point to BIRD route-server policy, public statistics and a public looking glass.

The live route-server pages make that listing more than a static catalogue entry. On 13 July 2026, the PANDA-IX IPv4 looking glass identified "PANDA-IX RouteServer v4 (RS1 Semarang)" with router ID 165.101.31.1, 362 days of uptime and a last reconfigure timestamp of 23 January 2026. It showed a set of configured neighbours, including several established IPv4 BGP sessions with received and exported route counts, and some neighbours in Active, Idle or Connect states. That difference is important. A configured neighbour is not the same as an established session, and an established session is not the same as a high-volume traffic path.

The IPv6 looking glass showed the same RS1 Semarang route-server identity and uptime, but with a smaller live IPv6 participant surface. Established IPv6 sessions were visible for a narrower set of ASNs than IPv4. PeeringDB's port records also show IPv6 addresses on only a minority of the 15 connection rows. IPv6 is therefore real at PANDA-IX, but it should not be assumed to mirror IPv4 coverage across every participant.

This combination supports a precise operating claim: PANDA-IX is observable as a working local exchange fabric with live route-server operation. It does not support a broader claim that every listed peer is exchanging useful traffic at all times, that every customer path is resilient, or that the exchange has site-level redundancy. The route server can be healthy while one customer session is idle. It can export routes while backhaul is constrained. It can run for 362 days while the building's power and cooling arrangements remain undisclosed.

That distinction protects the company from a false negative and readers from a false positive. The absence of a global announcement from AS154034 does not erase the live local exchange evidence. At the same time, live BGP sessions do not prove a resilient data-centre plant. PANDA-IX is an operating local node; its full failure behaviour remains unproven in the public record.

The commercial product is narrower than a generic data-centre label

The operator's public product language is unusually concrete. The colocation page prices 1U, 2U and 4U packages, each limited to network devices, with setup and interconnection included. There is no public full-cabinet offer, no published rack count, no power allocation per rack unit, no metered electricity rate, no floor loading, no remote-hands service-level table, no cross-connect schedule, no available cabinet inventory and no disclosed IT load. The offer looks like a meet-me room or regional exchange room more than a general enterprise data hall.

That narrower interpretation is not criticism. A regional ISP may need exactly one router in Semarang. A content or access network may want a small port and a local route-server session rather than a full rack. A young exchange can lower the economic threshold for peering by selling small units. If the facility succeeds, it can make local network traffic less dependent on faraway hubs.

The problem appears when the data-centre label is allowed to carry more than the evidence. A data-centre reader may expect published power density, independent utility paths, redundant mechanical systems, fire-zone documentation, service-level history and third-party assessments. The public SDCT record does not yet provide those. The exchange-room product can be useful without those disclosures, but the risk assessment must stay faithful to the product actually shown.

PeeringDB reinforces the narrow reading. The facility record lists 13 networks and one exchange, but no carriers in the carrier field. It provides a room-level hotel address, 400 VAC voltage and no disclosed diverse serving substations. It does not publish rack count, floor area, gross power, available power, cooling capacity, building certification or carrier-neutral meet-me details. PeeringDB is not an engineering audit, but its structured fields identify what is visible and what is not.

Other catalogues add little independent weight. Data Center Map's Semarang market page has been used as a market-discovery check, but catalogue omissions cannot prove that a facility is not operating. A derivative listing such as PQ.Hosting's SDCT page repeats room, voltage, network and exchange details that appear to track PeeringDB-style fields. These are useful corroborating signals for the same public footprint, not independent proof of engineering resilience.

The appropriate public description is therefore compact and constrained. Semarang Data Center publicly offers small network-device colocation and operates a local exchange from Hotel Pandanaran. It is not yet publicly evidenced as a large general-purpose data hall with disclosed design capacity, powered capacity, cooling capacity or failure-mode capacity.

Capacity has to be kept in layers

The most common error in evaluating a small exchange is to add visible numbers together and call the result capacity. PANDA-IX has at least four different capacity surfaces, and only some are public.

The first is commercial unit size. SDCT sells 1U, 2U and 4U packages. That is a unit of space, not a statement of total room capacity. It does not disclose how many racks exist, how many units are occupied, how many remain available, how much power is assigned to each unit, how much heat the room can reject, or how many additional customers can be added before redundancy is lost.

The second is nominal port capacity. PeeringDB's exchange page and netixlan data list 15 connections whose declared speeds sum to 138G. That is installed or listed edge-port capacity, not guaranteed throughput. A port total does not prove a non-blocking switch fabric, sufficient uplink/backhaul, enough power and cooling at line rate, or enough spare capacity after the largest switch, power component or carrier handoff fails. It is a useful inventory number, but not a resilience number.

The third is live route-server capacity. The IPv4 and IPv6 looking glasses show active route-server processes, neighbour states and route counts. That is stronger than a marketing statement because it shows current logical operation. It still measures BGP control-plane state, not end-to-end customer data-plane throughput. A route-server session can be established while actual traffic volumes are low, asymmetric, constrained by a downstream link, or vulnerable to a shared switch or riser.

The fourth is facility capacity. This is the least visible layer. PeeringDB lists 400 VAC as a voltage service, but voltage is not available load. Public records do not identify design MW, installed UPS output, battery runtime, generator rating, fuel reserve, cooling tonnage, heat load, spare rack units, contracted watts or facility expansion limit. No public source states whether SDCT can maintain full contracted load after a utility outage, a cooling fault, a generator failure or a switch failure. Usable capacity under failure is therefore not established.

This layering matters because a customer failure happens across layers. A network may have a 10 Gbps port that remains administratively up, but if the room is thermal-limited after one cooling unit fails, usable capacity may fall to a fraction of that number. A customer may have an active route-server session, but if its only fibre path enters through a shared hotel riser, the route disappears with a building event. A facility may have enough normal power to run every installed router, but not enough backed-up power to keep the same load online after a grid outage.

The correct language is disciplined. PANDA-IX has 138G of nominal listed port capacity. It has visible live BGP operation. SDCT offers small network-device colocation. Facility-level design, installed, powered, lit, operational and usable capacity under failure are not the same thing, and most facility-level capacity remains undisclosed.

Power is the first unresolved dependency

Power is the most important missing surface because every other claim sits on it. The operator says its colocation space comes with fully redundant power. PeeringDB lists 400 VAC and no disclosed diverse serving substations. Public sources do not identify the number of utility feeds, feeder routes, service capacity, transformer arrangement, switchgear, automatic transfer equipment, UPS topology, battery runtime, generator rating, fuel storage, refuelling plan, load-bank test or integrated utility-loss test.

The difference between "has backup power" and "can keep the service usable" is substantial. A UPS may bridge a short interruption but not a long one. A generator may start but not carry both IT and cooling load. A generator may serve the hotel as a whole, with priority and load-shedding rules that are not visible to exchange customers. A fuel store may last a few hours at partial load but less under full cooling demand. A transfer back to utility can fail after the outage has already been survived. None of those risks is unusual; they are normal data-centre dependencies.

They become risky when customers cannot see the boundary.

The wider Indonesian power context is not enough. PLN said in 2023 that it served 94 data-centre customers with 727.1 MVA and expected data-centre connection growth through 2027. That national figure is useful for context, but it does not tell a Semarang customer whether room 214 has two feeds, one feed, a shared hotel generator, a dedicated generator or a tested transfer path. Grid capacity, local distribution, building switchgear and room-level continuity are different layers.

Industry evidence keeps power near the top of the risk list. Uptime Intelligence's 2025 outage analysis again places power among the leading causes of serious data-centre outage impact. Uptime's Tier overview also shows why redundancy language has to be specific: redundant components, redundant distribution paths, concurrent maintainability and fault tolerance are not interchangeable. There is no public evidence that SDCT has Uptime Tier Certification, and the article does not assign any tier. The point is narrower: a resilience claim should name the failure path it survives.

For SDCT, a useful disclosure would be modest. It would state the number of utility services, whether they share a substation or route, the UPS configuration, battery runtime at current and maximum contracted load, generator capacity, generator start and transfer arrangement, fuel autonomy, refuelling plan and the date of the last integrated test. The test should show the route servers, exchange switch, monitoring and cooling staying up through loss of utility, generator acceptance and return to utility. Without that, "fully redundant power" remains a claim, not a demonstrated capacity state.

Cooling and fire control are building questions

A compact network room can overheat quickly. Routers, switches and optical equipment turn electrical power into heat, and a small room has less thermal mass than a large hall. A cooling fault can begin quietly: a compressor fails, a condenser fan stops, a controller locks up, a drain blocks or an outdoor unit loses power. Packets may keep moving while the room temperature rises. By the time sessions drop, the recovery window may already be short.

SDCT says its facility has cooling, temperature and humidity monitoring, strict access control and automatic fire suppression. Those are important elements, but the public record does not describe their engineering boundary. It does not state the cooling method, the number of cooling units, the heat load, the N+1 status, the alarm thresholds, the maintenance isolation steps, the power source for cooling, the suppression agent, the fire-alarm integration, the inspection status or the post-discharge restart plan.

The hotel setting turns these into building questions. A data room on the second floor may depend on condensers, pipework, drainage, electrical panels, risers and access corridors elsewhere in the building. Two cooling units are not independent if they share one condenser, breaker, controller or outdoor path. A room-level fire-suppression system does not answer what happens if a hotel-wide fire alarm forces evacuation, isolates power, opens doors, restricts access or triggers fire-brigade procedures. A dry equipment room still depends on building systems that may be outside the operator's direct control.

The relevant standards show the breadth of a complete facility disclosure. ANSI/TIA-942-C covers telecommunications, power, cooling, architecture, fire protection, safety, security and monitoring for data centres and computer rooms. Indonesia's standards catalogue includes SNI 8799-1:2023 for data-centre technical specification and SNI 8799-2:2023 for data-centre management systems. The public SDCT record does not claim certification against these standards. They are used here only to define the kinds of systems a serious room-level disclosure should cover.

The practical test is not whether the room has cooling or fire suppression in ordinary operation. It is whether the service remains safe and usable after one cooling component fails, after the building changes power state, after a fire alarm isolates access, or after suppression discharges. A customer does not need every proprietary drawing. It does need enough information to know whether its router is protected by independent systems or by shared building services with unknown priority rules.

Network diversity is not the same as fibre diversity

PANDA-IX's participant list is valuable. PeeringDB lists 14 peers and 15 connections. The netfac API returned 13 network-facility records at SDCT Data Center. The live looking glass shows established route-server sessions with several Indonesian ASNs. A regional exchange becomes useful through exactly this concentration: networks place routers in the same site so local traffic can stay local.

Concentration also creates a shared failure domain. PeeringDB lists no carriers in the facility carrier field. That does not prove there are no carrier handoffs, because a network may be present as a member, customer or peer without being entered as a carrier seller. It does mean the public record does not reveal building-access diversity. Multiple ASNs can share the same fibre entrance, riser, duct, pole line, manhole, road crossing, provider tail or upstream handoff. At the packet layer they are different networks. At the civil-engineering layer they may fail together.

The operator's APNIC routing policy for AS154034 references AS24521, PT Data Utama Dinamika, as import, export and default. AS24521 is also listed as a PANDA-IX participant. That supports a routing relationship, but it does not show whether AS24521 provides an independent transit path, whether the handoff is in the same room, whether the path leaves the building through a separate route, or whether the route carries any globally originated SDCT service today.

The right route evidence has three levels. The first is logical: upstreams, peers, route-server policy, accepted prefixes, export policy and failover preferences. PANDA-IX exposes some of this through its public looking glass and policy notes. The second is optical and service-level: which fibre provider or Ethernet service reaches the room, what handoff exists, what restoration term applies and where the first upstream aggregation point sits. The third is physical: building entrances, risers, ducts, street routes, bridge or road crossings and the point at which paths become genuinely separate.

The public record is strong at the first level and weak at the second and third.

This gap determines the failure mode. A road cut outside the hotel could interrupt several logical providers if they share a duct. Hotel refurbishment could disturb a riser. A shared switch, patch panel or power feed could take down otherwise distinct sessions. A single fire or access event could remove the room from service. None of these scenarios proves the facility is fragile; they show why "many ASNs" is not the same as "many physical routes."

Global route absence has to be interpreted carefully

Independent routing observers show a sharp fact: AS154034 is not currently visible as a global origin. Hurricane Electric's AS154034 page has shown no current global prefixes. RIPEstat's routing-status API reported zero IPv4 and zero IPv6 RIS peers seeing AS154034 on 13 July 2026, zero announced IPv4 and IPv6 space and zero observed neighbours. RIPEstat's announced-prefixes API returned an empty prefix list for the two-week query window ending 13 July 2026.

For a normal access ISP, that would be a strong warning that the network has no visible global service surface. For an exchange route-server ASN, it needs more careful handling. AS154034 is described in PeeringDB as "SDCT IX Route Server." The operator's PANDA-IX policy page uses 165.101.31.0/24 and 2001:df5:c140::/48 as exchange LAN resources. An exchange LAN can be intentionally absent from global routing while participants exchange routes locally. In that arrangement, global absence does not mean local failure.

The live looking glass is therefore more informative for local operation than a global-origin score. It shows RS1 Semarang running and exchanging routes with local neighbours. The global absence is still important, but for a different question: what is SDCT's external service design? If AS154034 is only a route-server identity, then global invisibility should be expected and publicly stated. If SDCT also intends to host customer services, management endpoints or transit-originated prefixes through its own ASN, then the absence of global announcements requires explanation.

Customer impact depends on which product is being tested. A PANDA-IX participant may reach local peers even when AS154034 has no global origin. A hosted device that needs external access may depend on the customer's own ASN, another upstream or AS24521. A monitoring system may be reachable through a separate path. These are different availability surfaces. A single "up" or "down" label hides the engineering question.

The clean test is layered. First, can participants reach the PANDA-IX route servers on IPv4 and IPv6? Second, do route-server sessions exchange expected prefixes? Third, do member-to-member paths carry representative traffic without unexpected detours? Fourth, can hosted or management services be reached from outside Semarang through more than one upstream or customer path? Fifth, what remains reachable when the whole room, not just one session, is unavailable? The current public record answers the first two better than the last three.

Failure path one starts with utility loss

A sustained utility outage around central Semarang is the simplest facility test. The exchange switch, route server, customer routers, monitoring and cooling should ride through the initial event. If the UPS and generator are dedicated to SDCT, the test is inside the operator's plant. If they are shared with the hotel, the test includes hotel load priority, generator controls, fuel use, exhaust, refuelling and the decision about which circuits remain energised.

The first vulnerable interval is very short. The UPS must hold voltage and frequency within equipment tolerance when utility power disappears. The second interval is seconds to minutes. A generator must start, synchronise and accept both IT and cooling loads. The third interval is hours. Fuel, ventilation, maintenance state and refuelling logistics determine whether the site survives a longer city event. The fourth interval is the return to utility, when transfer errors or power-quality problems can interrupt equipment after the outage appears to be ending.

For a PANDA-IX participant, the result is not uniform. A network with another Semarang site or a robust upstream path may reroute and pay mainly in latency or transit cost. A smaller provider whose only local exchange router sits in room 214 may lose local peering entirely. A content cache or business service behind one of those networks may remain reachable from the wider internet but become slower for regional users. A customer device hosted only at SDCT may disappear if power or cooling cannot be maintained.

The right evidence would be an integrated utility-loss test at representative load. It should timestamp utility loss, UPS transfer, generator acceptance, cooling continuity, route-server stability, switch state, customer port state, monitoring reachability and return to utility. It should state what load was tested and how much backed-up headroom remained. Without that, a redundancy claim cannot be converted into powered usable capacity.

Failure path two starts with cooling loss

Cooling failure is more subtle than power loss because the network may keep forwarding while the room is becoming unsafe. If one cooling component stops, the remaining system must remove the heat from routers, switches, optics and power conversion equipment. If the remaining system cannot hold temperature, operators may have to reduce load, shut down non-critical devices, open doors, deploy temporary cooling or accept thermal shutdown.

Room-scale facilities can be responsive because staff and customers may know the exact devices and layout. They can also be fragile because there may be fewer redundant components and less separation between systems. Public materials do not show which case applies to SDCT. The operator claims monitoring and cooling, but there is no public heat-load value, cooling topology, failure-mode capacity, maintenance method or alarm escalation procedure.

The hotel environment adds access dependency. A cooling unit may be reachable only through building service areas. Outdoor condensers may sit on a roof, facade or service yard. Drainage may cross hotel spaces. A building alarm or public-safety event may prevent immediate repair access. A second-floor room protects equipment from some ground-level water exposure, but it does not protect condenser power, external piping, switchgear, generator plant or fibre chambers if those are elsewhere.

The operational question is not whether SDCT can keep the room cool on an ordinary day. It is how long the exchange remains usable after the largest cooling component fails at the highest contracted load, and whether customers receive enough warning to move traffic before hard shutdown. A useful public result would show alarm thresholds, time-to-temperature limits, remaining cooling capacity, maintenance isolation and customer notification timing. Until then, cooling is an asserted support system rather than a verified failure path.

Failure path three is the meet-me room itself

PANDA-IX creates value by putting several networks in one place. The same design makes the meet-me room a common point of failure. A switch fault, patch-panel error, software problem, route-server restart, mistaken configuration, fibre-riser cut, building power event or access restriction can affect many participants at once.

Some failures are logical. A route-server software issue may interrupt multilateral peering while bilateral sessions continue. A route filter error may stop some prefixes from being exported while the port remains up. A customer may be established but receive zero routes. These failures are visible in route-server telemetry and can often be repaired by configuration.

Other failures are physical. A switch loses power. A shared cross-connect panel is disturbed. A single riser fails. A patch cable is moved. A shared room cooling event requires equipment shutdown. These failures are not solved by having multiple ASNs in the same place. They are solved by independent switching, independent power, clear patch management, physical separation, off-site alternate paths or customer designs that do not require the room to be available for all traffic.

The public PANDA-IX record shows RS1 Semarang. It does not prove an independent second route server, independent switch path or second exchange site. PeeringDB lists one local facility for PANDA-IX. A second switch in the same rack would reduce some component risk but not a room or building risk. A second exchange location on a different utility and fibre path would address more of the site-level risk, but there is no public evidence of one.

That is acceptable if the service is priced and described as a single-site exchange. Many young IXPs begin there. The risk appears when single-site service is read as regional resilience. The honest design advice is simple: PANDA-IX may improve local traffic economics, but members that need continuity should maintain external transit and, where possible, alternate peering or hosting paths outside room 214.

Failure path four is Semarang's wider hazard surface

Semarang's physical setting is not just background. The World Bank's Semarang flood-risk dataset identifies city exposure to tidal flooding linked to subsidence and to local or river flooding after heavy storms. A World Bank project assessment describes coastal, fluvial and pluvial flood hazards, drainage constraints, rivers and land-subsidence context. Semarang's disaster agency published a 2025 flood-risk map, and the city issued an emergency-alert decree for flood, landslide and extreme weather in January 2025.

These sources should be used carefully. They do not prove that Hotel Pandanaran is in a specific flood-risk band, and they do not prove SDCT has suffered any flood damage. A parcel-level assessment would need site elevation, drainage, equipment placement, historical water levels, utility-room locations and street access. The public article should not imply more than the maps support.

The hazard still matters because a second-floor room depends on systems below and around it. Racks can be above shallow water while the building entrance, basement equipment, external switchgear, generator, fuel delivery, street duct, fibre chamber or technician access route is not. Flood can also cause power isolation, access restriction, traffic disruption and delayed repair even if the room remains dry. A local exchange does not have to be underwater to be unavailable.

Fire is similar. A room-level suppression system may protect equipment inside room 214, but a fire elsewhere in the hotel could trigger evacuation, power isolation, smoke movement, water response, restricted access or inspection delays. Customers need to know who can re-enter, who can restart equipment, how smoke or suppression exposure is assessed, and how traffic is moved while the building is unavailable.

The correct resilience claim is not that Semarang is too hazardous for infrastructure. Regional infrastructure has to be built where regional users are. The claim is that hazard evidence should push the operator toward clear placement and recovery disclosures: equipment elevation, protected fibre entry, electrical-room location, generator placement, water detection, fire-compartment rating, access procedures and off-site recovery options.

The people affected are not just listed peers

PANDA-IX's visible customers are networks. Its affected users are wider. When a local exchange fails, the immediate loss may be a BGP session between operators, but the felt effect can be slower pages, longer voice paths, game jitter, higher transit cost, unstable content delivery or a business service that takes a longer route. End users do not need to know the exchange exists to feel its absence.

Impact varies by member design. A larger network with multiple transit providers and another interconnection site can keep service running, although it may shift traffic to a longer or more expensive path. A smaller ISP with one router at SDCT may lose a local handoff and fall back to a single upstream. A customer hosting equipment in the room may lose reachability if its own device loses power, cooling, port state or upstream path. A content or cache deployment may continue to serve some networks but not others.

This is why uptime should be measured through representative traffic, not only through a route-server process. A route server can be up while some members receive no prefixes. A switch can be up while a congested upstream path changes the user experience. A room can be powered while cooling limits force traffic drain. Conversely, a route-server restart may have little user effect if members maintain bilateral sessions.

SDCT could make this impact legible by publishing aggregated exercise results. Members could test route-server restart, switch maintenance, port loss, one upstream failure, utility-loss transfer, cooling alarm and complete room unavailability. The results could show convergence time, packet loss, latency change and usable remaining capacity without naming customer traffic. Such tests would turn a small regional exchange from a promise into a measured dependency.

What the present evidence proves

The current evidence proves several important things. PT Semarang Data Center is the company tied to the SDCT identity and AS154034. The company publicly offers small colocation packages for network devices in Semarang. The data-centre address is Hotel Pandanaran, second floor, and PeeringDB narrows the facility to room 214. PANDA-IX is listed as a Semarang exchange at that facility. It has 14 peers, 15 listed connections and 138G of nominal port capacity in PeeringDB. Its public looking glass shows live RS1 Semarang operation, including IPv4 and IPv6 BGP sessions.

The evidence also proves what should not be claimed. The public record does not show that SDCT owns the building systems that support room 214. It does not show dual utility feeds, diverse substations, independent power paths, UPS capacity, generator runtime, fuel reserve, cooling redundancy, fire integration, carrier entrance diversity, multiple route servers on independent infrastructure, a second exchange site, live traffic volume, customer failover history, or usable capacity after failure. The absence of those disclosures is not proof that the systems do not exist. It is proof that a public resilience assessment cannot rely on them.

The global route evidence is also bounded. RIPEstat and Hurricane Electric show no current global announcements for AS154034. That should be recorded because it matters for external reachability. It should not be misread as proof that PANDA-IX is down, because the route-server surface is visible locally. The unresolved question is what AS154034 is meant to do outside the exchange LAN.

Five facts would change the assessment quickly. First, a physical responsibility map showing what SDCT controls and what the hotel controls. Second, a simplified electrical and cooling topology with tested failure-mode capacity. Third, a carrier and fibre-entry map that identifies where paths become physically separate. Fourth, a capacity table that separates rack units, contracted watts, installed port speeds, measured traffic and failure-mode headroom. Fifth, dated failover exercises covering utility loss, cooling loss, route-server restart, switch failure, fibre entrance failure and full room unavailability.

Until then, Semarang Data Center should be treated as a credible local exchange operator with an unresolved facility-resilience case. That is a narrower judgment than a promotional data-centre profile and a fairer one than dismissing the exchange because its route-server ASN is not globally visible. The company has made the local node observable. The next step is to make the dependencies around the node equally observable.

A regional exchange earns trust by showing its constraints

Semarang Data Center's strongest contribution is local. It gives Central Java networks a visible place to meet, and the live route-server evidence shows that the exchange is not just an announced idea. For a regional market, that matters. A small number of local ports can change how traffic moves, especially when the alternative is a longer haul to a larger hub.

Its weakest public surface is also local. The exchange sits in a room inside a hotel, and the systems around that room are not fully disclosed. Power, cooling, fire control, access and fibre routes are the infrastructure underneath the BGP sessions. If they fail together, the exchange's logical diversity disappears. If they are independent and tested, the site can earn more trust than its small footprint suggests.

The company does not need to pretend that room 214 is a hyperscale campus. It needs to define what the room is, what it is not, what capacity is actually installed, what capacity is actually lit, what capacity is actually powered, what capacity is available for sale and what capacity remains usable after a plausible failure. That language is more valuable than a large headline number. It lets customers decide which risks they can accept and which they must design around.

The current conclusion is therefore deliberately restrained. PANDA-IX is a functioning local exchange surface with current public route-server evidence. Semarang Data Center is the company and facility identity behind that surface. The broader data-centre resilience claim remains an engineering question until the operator shows the physical power, cooling, access and backhaul paths that keep the room alive when normal conditions disappear.