Summary
- PT Semarang Data Center is a young Central Java operator whose clearest operating evidence is PANDA-IX: its public route server was reporting 359 days of uptime on 10 July 2026, with live IPv4 and IPv6 sessions and a populated local peering LAN.
- The commercial facility is identified as room 214 on the second floor of Hotel Pandanaran in Semarang. Public offers cover only 1U, 2U and 4U packages for network devices, which points to a compact interconnection-led product rather than a disclosed general-purpose data hall.
- Public records do not establish dual utility feeds, independent substations, UPS topology, generator runtime, fuel arrangements, cooling redundancy, separate fibre entrances, certified resilience, available rack capacity or tested customer failover.
- AS154034 is not currently visible in global routing, but that does not by itself mean PANDA-IX is down. A route-server ASN can support local exchange sessions without originating a globally reachable service prefix; live exchange telemetry is therefore more informative than the ASN headline alone.
A small room with a large promise
The most consequential fact about Semarang Data Center is not its autonomous system number. It is the address attached to the physical service: the second floor of a working hotel on Jalan Pandanaran, close to the commercial centre of Semarang. That setting makes the company a revealing test of what regional digital infrastructure can be. It can be compact, inexpensive and useful to local network operators. It can also inherit dependencies that a purpose-built campus would normally expose in engineering schedules, resilience certificates and utility diagrams.
PT Semarang Data Center says it was established in February 2025 to provide colocation in Central Java. Its website offers spaces of 1U, 2U and 4U, explicitly for network devices, at published monthly prices. It also operates Panda Internet Exchange, or PANDA-IX. The same page promises fully redundant power, continuous environmental monitoring, automatic fire suppression, controlled access and round-the-clock support. Those are material commitments. They describe the systems that must remain available when city power fails, a cooling unit stops, a fibre route is cut or maintenance is performed.
The public footprint contains enough live network evidence to show that the proposition is not merely aspirational. PANDA-IX has active routing sessions, exchange addresses and traffic-monitoring infrastructure. Yet that evidence is much richer on BGP than on the building systems keeping BGP alive. The result is an unusual inversion: outsiders can see how many prefixes several participants deliver to the route server, but not how long the batteries can carry the room or whether the generator can run through an extended outage.
For a regional interconnection point, that imbalance matters. A customer does not buy resilience by buying a rack unit. It buys a chain: utility service, switchgear, UPS, battery, generator, fuel, cooling, fire control, building access, fibre entrance, cross-connect, route server and staff response. The weakest common dependency defines the result. Semarang Data Center's opportunity is to make that chain visible and testable. Until it does, PANDA-IX can be described confidently as a live local exchange, while the broader data-centre resilience claim remains only partly evidenced.
The operating case is strongest on the peering LAN
The company received AS154034 in July 2025. The APNIC record for the ASN identifies PT Semarang Data Center as a direct IDNIC member and records a routing policy involving AS24521, PT Data Utama Dinamika. Separate APNIC records assign the operator 165.101.31.0/24 and 2001:df5:c140::/48 as portable IPv4 and IPv6 space. The company's policy page uses those blocks for the PANDA-IX peering LAN.
The exchange itself is more visible than many very small regional facilities. On 10 July 2026, PANDA-IX's public IPv4 looking glass identified a BIRD 2 route server with router ID 165.101.31.1, 359 days of uptime and a reconfiguration date of 23 January 2026. It showed established sessions receiving routes from networks including AS142360, AS55666, AS59273, AS38515, AS132663, AS24521, AS153729 and AS149704. Some configured neighbours were in Active or Idle state, and two established peers were receiving zero prefixes. That distinction is important: a configured participant, an established session, a received route and an exchanging customer are four different claims.
The IPv6 looking glass showed a thinner fabric. Three participating ASNs had established IPv6 sessions across four ports, because AS55666 appeared twice. IPv6 was therefore operational, not universal. PeeringDB's exchange listing similarly showed IPv6 addresses on only five of the 15 port records. For a new regional exchange, partial IPv6 adoption is unsurprising; for a customer assessing path resilience, it means IPv4 and IPv6 should be tested independently rather than treated as equivalent services.
PeeringDB listed 14 networks and 15 exchange connections, with an aggregate of 138 gigabits per second in declared port speeds. The difference between networks and connections comes from AS55666 having two 10 Gbps ports. The list ranged from 1 Gbps ports to one 25 Gbps port, with most at 10 Gbps. BGP.tools independently displayed the same 15-router, 14-ASN shape. These records, combined with the live looking glass, support the conclusion that PANDA-IX is operating as a local exchange fabric.
They do not prove that 138 Gbps is available end-to-end capacity. Port speed is the configured edge of a connection, not measured traffic, guaranteed backhaul or usable failover throughput. Fifteen ports can also share one switch, one power path, one riser or one carrier duct. A list of distinct ASNs is evidence of commercial participation; it is not a physical diversity diagram.
The commercial product looks more like a meet-me room than a data hall
Language matters because customers attach different expectations to a data centre, a carrier hotel, an exchange room and a server room. Semarang Data Center markets itself as a data-centre colocation provider, but the product it publicly prices is narrow. A 1U package costs IDR1 million a month, 2U costs IDR2 million and 4U costs IDR3.6 million. Each package says it is only for network devices and includes setup and interconnection. There is no published full-cabinet offer, power allocation per rack, metered energy rate, remote-hands schedule, cross-connect fee, floor loading, rack count or available IT load.
That does not make the product less useful. For a Central Java ISP, placing a router in Semarang can shorten the path to another regional network, avoid hauling every local flow through Jakarta and create a place for bilateral interconnection. A few rack units may be exactly the right unit of sale. The problem is classification. If the commercial purpose is predominantly to host routers and an exchange switch, the facility should be assessed first as an interconnection site. Its critical outputs are live ports, route-server availability, stable environmental conditions and access to repair equipment. It should not be assumed to offer the workload density, storage environment or enterprise continuity controls associated with a large multipurpose data hall.
The PeeringDB facility entry reinforces this interpretation. It places SDCT Data Center in room 214 on the second floor of Hotel Pandanaran, records 13 networks and one local exchange, and discloses 400 VAC service. It does not list a carrier in PeeringDB's carrier field. It marks diverse serving substations as not disclosed. It provides no public value for floor area, rack count, gross power, available power or certifications. PeeringDB is self-reported and does not inspect the facility, but its structured omissions identify the questions a buyer still has to answer.
Public catalogue coverage is also mixed. Data Center Map's Semarang market page lists two other facilities, not SDCT. A third-party catalogue reproduces the PeeringDB entry and calls SDCT active, but adds no independent engineering detail. Neither absence nor repetition proves operating quality. They suggest that the facility is new and not yet documented across the established colocation market. The evidence capable of settling that is not another catalogue listing; it is a customer-ready technical schedule and test history.
Two addresses define the ownership boundary
The company and the equipment are not presented at the same address. APNIC, APJII and the corporate listing place PT Semarang Data Center at Jalan Sumbawa II No.3 in Karangtempel, Semarang Timur. The facility listing and the company's own contact section place the data-centre room at Hotel Pandanaran, Jalan Pandanaran No.58. The hotel's own website confirms that street address and describes an operating hospitality property with rooms, food, a swimming pool, a lounge and full Wi-Fi coverage.
This separation creates at least three operating domains. PT Semarang Data Center controls the exchange and colocation service. The hotel or building owner controls some portion of the property systems. PLN and telecommunications providers control off-site utility and fibre assets. Public materials do not say whether SDCT owns room 214, leases it, operates under a managed-space agreement or shares electrical and mechanical systems with the hotel. They also do not divide responsibility for switchgear, generator testing, fire detection, suppression, chilled air, water ingress, lifts, loading access or after-hours entry.
That boundary is not an administrative detail. Imagine a generator that belongs to the hotel but supplies the exchange room. Who sets the maintenance interval, fuel reserve and priority load? If a cooling unit serving room 214 is dedicated to SDCT, who can isolate and replace it without breaching the hotel envelope? If a fire alarm closes the building, can network engineers enter under an emergency procedure? If roof work threatens a fibre riser, who notifies customers? Every one of those questions has an owner, even when the answer is not public.
The best evidence would be a responsibility matrix attached to customer contracts. It would name the owner of each asset from the utility meter to the customer socket, state the maintenance authority and identify the person empowered to declare an incident. A landlord letter, approved room use, electrical single-line diagram, fire-system integration document and access procedure would make the operational boundary legible. Their absence from public view is not evidence of noncompliance. It means buyers cannot infer resilience from the PT company name or the hotel's continued operation.
Power is the first unresolved dependency
The operator's website uses the phrase "fully-redundant power" but gives no topology. PeeringDB discloses 400 VAC and nothing about diverse serving substations. No public material identifies utility feeders, service capacity, automatic transfer switches, UPS modules, battery chemistry, autonomy at design load, generator rating, fuel storage, refuelling contracts or load-bank tests. There is also no published distinction between installed capacity and sellable customer power.
That gap deserves priority because power faults remain a leading cause of serious data-centre outages. Uptime Intelligence's 2025 outage analysis again found power issues to be the most common cause of serious and severe events. The lesson is not that every small exchange needs a hyperscale electrical plant. It is that the word redundant must describe independent capacity and distribution paths, not merely the presence of a UPS and a generator on the same downstream board.
Indonesia has ample national interest in supplying data centres. PLN said in 2023 that it served 94 data-centre customers with 727.1 MVA and expected substantial new connections through 2027. That national capacity story does not answer a room-level question in Semarang. Grid reserve, local feeder diversity, building switchgear and on-site ride-through are different layers. A healthy Java-Bali system cannot prevent a breaker fault, cable damage or maintenance error between the local substation and room 214.
For SDCT, the minimum useful disclosure would be modest: utility service count; whether feeds share a substation or route; UPS configuration; battery runtime at current and maximum contracted load; generator start design; generator runtime at that load; fuel replenishment arrangements; and the date and result of the last integrated test. The test should simulate loss of utility, not simply start the generator unloaded. It should show the route server, exchange switch, cooling and monitoring staying online through transfer and return.
Usable capacity should then be stated after resilience reservations. If the room has, for example, a certain amount of installed UPS output, some portion must be reserved for failure conditions, cooling, conversion losses and growth. Selling every nominal amp would turn maintenance or a single module failure into load shedding. Without the numbers, no outsider can calculate how many additional 4U customers the present system can support or whether the advertised redundancy survives full occupancy.
Cooling and fire control need the same precision
Network devices convert nearly all consumed electrical power into heat. A compact room can therefore reach unsafe temperatures quickly after cooling loss, even if the IT load is small by campus standards. SDCT says it continuously monitors temperature and humidity and has automatic fire suppression. It does not identify the cooling method, number of units, maintenance arrangement, temperature envelope, alarm thresholds, heat-rejection path or suppression medium. It also does not disclose whether cooling rides through a utility transition or depends on a generator that starts after the UPS has taken the network load.
The distinction between redundancy and recoverability is especially important in a room within another occupied building. Two indoor cooling units are not independent if they share one outdoor condenser, control circuit, distribution board or blocked airflow path. Two fire detectors are not an operational plan if a building-wide alarm isolates power or denies access. A local gaseous-suppression system can protect equipment from water, but its integration with the hotel's life-safety system, evacuation policy and fire brigade response still matters.
Current technical benchmarks show the breadth of the issue. ANSI/TIA-942-C, published in 2024, covers telecommunications, power, cooling, architecture, fire protection, safety, security and monitoring for data centres and computer rooms of any size. Indonesia's standards catalogue lists SNI 8799-1:2023 for technical specifications and SNI 8799-2:2023 for data-centre management. The public record does not show SDCT claiming certification against these standards. They are useful here as a map of the systems that a serious technical disclosure should cover, not as a grade the facility can be assigned from outside.
Evidence of cooling resilience would include the design and measured heat load, N+1 status at the highest contracted load, power source for each cooling component, maintenance isolation steps and a controlled cooling-failure test. Fire evidence would include the detection method, suppression design, inspection status, cause-and-effect sequence and post-discharge recovery plan. Those documents would do more than add a badge. They would reveal whether a single service visit or control-board failure can stop the exchange.
Network diversity is not the same as fibre diversity
PANDA-IX's participant list is the strongest part of SDCT's proposition. Fourteen ASNs on the exchange give local operators a credible set of possible counterparties. PeeringDB also lists 13 networks as present at the facility, including the route server. The PANDA-IX peering matrix says it derives activity from sFlow traffic and route-server sessions, while warning that observed bidirectional TCP flows do not prove prefixes were exchanged. That is a healthy caveat: it distinguishes configured presence from traffic-producing interconnection.
Physical diversity is still unresolved. PeeringDB lists no carriers for the facility, even though the company advertises multi-provider connectivity and the network list contains several service providers. Those facts can coexist. A network may be present as a customer or peer without being recorded as a carrier that sells building access. Multiple networks may also arrive over leased capacity in one cable, one duct, one pole route, one manhole or one hotel riser. At the packet layer they are different ASNs; at the civil-engineering layer they may share a failure point.
The APNIC routing policy for AS154034 names AS24521 as an import, export and default relationship. AS24521 is also a 10 Gbps PANDA-IX participant. That supports a relationship in routing configuration, but it does not establish two independent transit providers or a physically separate path into the building. Nor does it show whether AS154034's transit relationship is currently carrying a globally originated service prefix.
A customer evaluating backhaul should ask for route maps at three levels. The first is logical: upstreams, peers, accepted prefixes and failover policy. The second is optical: fibre owner, handoff location, wavelength or Ethernet service and restoration terms. The third is physical: building entrances, risers, ducts, road crossings and the first point at which routes become truly separate. Carrier diversity is achieved only when the paths avoid the same plausible incident.
That incident could be local and mundane. Road excavation can cut several providers in one duct. A hotel refurbishment can disturb a shared riser. One core switch can concentrate every cross-connect. A power event can disable otherwise diverse carrier equipment in the same room. SDCT's live exchange proves that packets move today. A documented route-diversity design would show which packets continue moving after one of those events.
Why the global routing withdrawal is not an outage verdict
Hurricane Electric reports that AS154034 has not been visible in the global routing table since 18 December 2025. Its page currently shows zero announced IPv4 or IPv6 prefixes. The associated 165.101.31.0/24 page also says the prefix is not globally visible. RIPEstat's routing-status endpoint showed zero visible IPv4 and IPv6 space across its collectors on 10 July 2026, and its recent announced-prefix view returned no prefixes for the preceding two weeks.
Read in isolation, that sounds like a failed network. In this case it is not enough to support that conclusion. AS154034 is described in PeeringDB as an IX route server, and its assigned prefixes are used as the PANDA-IX peering LAN. An exchange LAN can be intentionally absent from global routing while its members reach one another directly over local ports. The live IPv4 and IPv6 looking glasses show precisely that local function: established BGP neighbours, received routes and a route-server process that had been up for almost a year.
The apparent contradiction therefore separates two products. PANDA-IX can operate locally without AS154034 advertising its peering LAN to the world. A public service hosted by SDCT, by contrast, needs a globally reachable path through a customer's ASN or an SDCT transit design. The withdrawal matters if the company expects AS154034 to originate management, hosting or customer prefixes globally, or if its intended AS24521 transit path is supposed to provide remote access to infrastructure. The current public record does not explain that design.
The right operational test is layered. Can every active PANDA-IX participant reach the route servers over IPv4 and, where configured, IPv6? Do routes continue to exchange when one route-server session or switch path fails? Can customers reach their own hosted equipment from outside Semarang through independent upstreams? Are monitoring and support systems reachable during a local exchange incident? A single global-visibility score cannot answer all four.
The discrepancy is valuable because it prevents an easy but wrong judgment. Registry allocation is not proof of service. Global withdrawal is not proof of local failure. Live local telemetry is strong evidence of exchange operation, while external reachability and failover require separate customer-path tests.
Nominal capacity is not sellable resilience
Three public numbers could easily be mistaken for capacity. PeeringDB assigns the route-server network a self-reported traffic band of 5-10 Gbps. Its exchange page totals 138 Gbps of participant port speeds. A public MRTG page for a core SDCT interface labels a maximum speed of 100 GBytes per second and showed only kilobits per second of traffic when checked on 10 July 2026. These figures describe different things, and none establishes the amount of traffic the facility can deliver under failure.
PeeringDB's traffic band is a category supplied for the network profile, not an audited meter. The 138 Gbps total is the sum of nominal edge-port rates, not a promise that all ports can transmit at line rate simultaneously. The MRTG page appears to cover a specific trunk and uses an implausible unit label for its configured maximum; its low observed traffic cannot be assumed to represent the entire exchange. The company should not be judged by combining these numbers, but customers should not use them as substitutes for engineering capacity either.
Installed capacity becomes usable capacity only after oversubscription, switch fabric, uplink design, power, cooling and failure reservations are accounted for. If a 25 Gbps participant and several 10 Gbps participants share a constrained trunk, the port total overstates simultaneous throughput. If the switch fabric can carry the traffic but one power feed cannot support the room after a failure, electrical capacity is the binding limit. If cooling loses redundancy above a certain heat load, thermal capacity is lower still.
The most useful publication would show a simple set of ratios without exposing customer-sensitive traffic. SDCT could state total installed customer port capacity, non-blocking switch capacity, normal peak aggregate traffic, headroom under normal conditions and headroom after loss of the largest switch, power module or cooling unit. It could do the same for rack units and contracted watts. This would let customers distinguish growth space from resilient growth space.
Small facilities often have an advantage here. Their systems are easier to describe, their failure domains can be physically inspected and their customer base can coordinate maintenance. Transparency does not require a 100-page report. It requires numbers that refer to the same boundary and a test that demonstrates the claimed spare capacity is real.
Failure path one: utility loss exposes the whole building chain
Consider a sustained utility outage affecting central Semarang. The exchange switch and route server should transfer immediately to energy storage, while the generator starts and cooling continues. The hotel's other essential loads may also call on backup generation. If SDCT has a dedicated generator and transfer path, the hotel demand is irrelevant. If it shares the building plant, load priority and fuel consumption become part of the exchange's availability model.
The first vulnerable interval is measured in milliseconds: power quality must remain within equipment tolerance while the UPS takes the load. The second is measured in seconds: the generator must start, stabilise and accept both IT and cooling demand. The third is measured in hours: fuel, lubrication, ventilation, exhaust and refuelling must sustain operation. The fourth is the return to utility, when transfer errors can undo a successful ride-through. A generator start log proves only one part of the sequence.
Who is affected depends on customer design. A network with another active Semarang location may reroute. A customer using SDCT as its only local handoff may lose local peering and send traffic over a longer path, if transit remains available. A device hosted only in room 214 may become unreachable. PANDA-IX participants whose bilateral and multilateral sessions share the same room could lose both at once. The event can therefore raise latency without disconnecting end users, or it can remove an entire regional path, depending on each member's topology.
The recovery evidence should be an integrated utility-failure exercise at representative load, with timestamps for UPS transfer, generator acceptance, cooling continuity, route-server sessions and customer port state. It should include a fuel assumption and a method for restoring service if the generator fails to start. Without that evidence, "fully-redundant power" communicates an intention rather than a demonstrated recovery capability.
Failure path two: cooling loss can outlast the UPS
A cooling event may begin without any loss of packets. A fan, compressor, condenser, controller or power circuit fails; room temperature rises; equipment fans accelerate; power demand increases; and only later do devices throttle or shut down. That delay makes thermal incidents deceptive. A network graph can look healthy while the time available for intervention is shrinking.
Room 214's placement inside a hotel adds questions about the heat-rejection route. Outdoor equipment may be on a facade, roof or service area. Pipework, drainage and controls may cross spaces not managed by SDCT. None of those configurations is inherently unsafe, but each creates maintenance and access dependencies. Public materials do not identify them.
The relevant measure is not the number of air-conditioning units. It is whether the remaining system can hold the contracted IT load within limits after the largest cooling component or distribution path is unavailable. That should be demonstrated during hot ambient conditions, with door openings and realistic network load. Alarm delivery should also be tested outside normal hours, because 24/7 support has value only if someone can diagnose and act before thermal shutdown.
Customer failover should treat a cooling alarm as a service risk before equipment disappears. Networks can lower local preference, drain traffic or move critical services while the room remains reachable. SDCT can help by defining alert thresholds and providing a customer notification window. This is where a small operator can be more responsive than a large campus: the customer and facility teams can know the same room, devices and routes. That operational intimacy becomes a strength only when it is formalised.
Failure path three: a meet-me interruption can defeat many networks at once
The exchange's member count creates value through concentration. It also concentrates failure. A core-switch fault, configuration error, loop, shared cross-connect panel failure or fibre-riser cut can affect multiple ASNs at the same moment. The route server itself can fail without stopping bilateral peering, but only if customers have configured bilateral sessions and the switching fabric remains available. Two logical route servers on one switch and power path would not protect against a common physical event.
The public IPv4 view exposes one route-server instance, RS1 Semarang. It does not show a second independently powered route server or a second exchange switch. That is not proof that none exists; it defines the limit of what can be verified. PeeringDB lists a single local facility for PANDA-IX. There is no disclosed second site to which members can extend the same exchange service.
Recovery should therefore be tested at the component and site levels. Component tests include route-server restart, switch supervisor failure, software upgrade, port-channel member loss and configuration rollback. Site tests ask whether customers can maintain regional connectivity when the entire room is unavailable. A second switch in the same rack may solve some component failures. A second peering site on a different utility and fibre route is needed for a building-level event.
For many small ISPs, a second site may be too expensive at launch. The honest alternative is to define the service as single-site and help members design external recovery through transit or another exchange. Availability improves when the operating boundary is explicit. It deteriorates when nominally different sessions share dependencies that customers do not know about.
Failure path four: flood and fire are building events, not rack events
Semarang's broader hazard profile cannot be ignored. The World Bank describes the city as exposed to coastal, river and rainfall flooding, with low-lying areas, nine principal rivers, constrained urban drainage and land subsidence. Its flood-risk dataset identifies both tidal flooding linked to subsidence and short-duration local or river flooding after heavy storms. Semarang's disaster agency published an updated 2025 flood-risk map, and the mayor declared an emergency-alert status for flood, landslide and extreme weather in January 2025.
Those city-level materials do not establish that Hotel Pandanaran itself is in a particular risk band. A site-specific drainage, elevation and access study would be needed for that. The second-floor room may reduce direct equipment exposure to shallow surface water, but elevation of the rack does not elevate utility switchgear, generators, fuel systems, fibre chambers, street access or building entrances. A dry room can still be isolated by a wet city block.
Fire produces the opposite vertical problem. A fire elsewhere in the hotel may trigger building evacuation, power isolation, smoke movement, sprinkler operation or restricted access even if room 214 is untouched. An automatic suppression system inside the room addresses only part of the scenario. Customers need to know whether the exchange can remain energised safely, who can authorise re-entry and how equipment is inspected before restart.
The correct response is not to treat every Semarang site as unfit. Regional infrastructure must exist where regional users are. It is to price and design for the local hazard. The evidence would include site elevation, drainage route, location of electrical and generator equipment, protected fibre entry, water sensors, fire-compartment rating, suppression inspection and an alternate access plan. A periodic exercise should assume the building is unavailable, not just that one device has failed.
The people affected are wider than the customer list
PANDA-IX's direct customers are network operators, but a failure propagates to people who may never have heard of the exchange. An ISP that loses a local peer may send traffic through Jakarta or another hub, increasing distance and congestion. A content path may remain available but slower. Real-time calls, games, payments and hosted business systems feel that change before a complete outage appears.
The impact is uneven. Networks with robust transit and another exchange path can absorb the loss, paying in latency or transit volume. A smaller provider with one router at SDCT and one external uplink may face a sharper choice between local reachability and full disconnection. A university, hospital or business whose service is hosted behind one of those networks inherits the provider's design even though it has no contract with SDCT.
This is why customer failover evidence matters more than a generic uptime percentage. A route server can achieve high process uptime while customers still have fragile end-to-end paths. Conversely, one route-server outage may have little effect if members maintain bilateral sessions. The meaningful measurement follows representative traffic from end user to destination across a failure, recording convergence time, packet loss, latency and capacity after rerouting.
SDCT could make regional resilience measurable by organising member exercises. Participants would withdraw selected routes, disable a port, simulate loss of the route server and test remote access through alternate paths. Aggregate results could be published without exposing commercial details. The exercise would reveal which dependencies are facility-wide and which customers have designed around them.
What would change the assessment
The evidence supports a clear present-tense conclusion. PT Semarang Data Center is a registered company and APJII corporate member with assigned number resources. PANDA-IX has a live route server, configured participants, established BGP sessions and public monitoring. The hotel-based facility is listed with multiple networks and a current commercial offer. These facts are enough to describe an operating regional interconnection service.
The evidence is not enough to assign a resilience class or verify the broader continuity promises. Five disclosures would change that quickly.
First, publish the physical boundary: room size, rack count, maximum IT load, current contracted load, expansion limit, site owner and responsibility split with the hotel. Second, publish a simplified electrical and cooling topology with component redundancy, maintenance isolation and failure-mode capacity. Third, identify carrier entrances and the point at which fibre paths become physically diverse. Fourth, provide current fire, electrical and applicable building approvals together with any independent data-centre assessment. Fifth, publish results from utility-loss, cooling-loss, route-server, switch and customer-failover exercises.
The operator should also reconcile its network views. PeeringDB lists 14 ASNs and 15 ports; its live IPv4 route server shows several peers established, several Active or Idle and a configured address not present in the current PeeringDB list. The public member page shows a smaller set and includes special content entries. These differences may reflect normal timing, policy and configuration changes. A dated operational-status page could separate contracted members, provisioned ports, established route-server sessions and traffic-active peers.
Finally, SDCT should explain the role of AS154034 outside the exchange LAN. If it is intentionally only a route-server identity, the lack of global announcements is expected and should be stated. If it is also intended to provide transit or public management reachability, the operator should identify the active origin and failover design. Clarity would prevent both false alarms and inflated assumptions.
A regional facility earns trust by making constraints visible
Semarang does not need every digital service to travel through Jakarta. A local interconnection point can reduce unnecessary distance, create a meeting place for Central Java networks and give smaller operators a practical first step into peering. SDCT's low-unit offers lower the commercial threshold further. A provider can place one router rather than commit to a full cabinet. The exchange's live BGP sessions show that this proposition has attracted real participation.
The next stage is not simply more logos or larger port totals. It is evidence that the room can carry its present community through failure. In a hotel-based site, that means showing exactly which systems are dedicated, which are shared and how shared systems are governed. In a flood-prone city, it means looking below the second-floor rack to street access, generator placement and fibre chambers. In a growing exchange, it means distinguishing nominal ports from active sessions and active sessions from recoverable traffic.
The company can turn its small scale into an advantage. It can publish concise diagrams, invite customer witnesses to integrated tests, expose current route-server state and document every common dependency. It can make maintenance windows legible and help members build alternate paths. None of this requires pretending that room 214 is a hyperscale campus. It requires defining what the facility actually is and proving that the promised service survives within that boundary.
Semarang Data Center has already crossed the first threshold: PANDA-IX is observable as a working regional exchange. The harder threshold is operational trust. That will be reached when a customer can trace two genuinely independent paths for power and connectivity, see cooling capacity after one failure, understand the hotel boundary and review a successful failover exercise. Until then, the exchange is a credible local node with an unresolved resilience case, and every new rack unit makes that case more important.