Summary
- PT Omni Data Center Indonesia presents a two-site offer: BTM1 in Batam and JKT1 in Jakarta. Its own BTM1 sheet states 680 m2 of phase-one colocation space and 1.2MW of IT load, while its Jakarta sheet states 864 m2 of phase-one space but does not disclose a total IT-load figure.
- Independent records support the existence and current network use of both locations. PeeringDB lists 13 networks at Batam and 18 at Jakarta, and an ISEAS - Yusof Ishak Institute report classifies Omni's Batam facility as an extra-small site in operation. Those records do not prove that all marketed power, cooling or rack capacity is installed, energised, unsold and deliverable.
- The public Uptime Institute directory records Tier III Certification of Design Documents for JKT1's IT Hall 1 on the second floor. It does not list a Constructed Facility award for Omni, and it does not attach the published award to BTM1. Design certification validates engineering documents, not the installed environment or day-to-day operations.
- OMNIIX has observable activity: PeeringDB showed 30 entities, nine listed facilities and a 10Gbps route-server connection for AS56868 on 15 July 2026. But logical access to one exchange fabric is not proof of independent carriers, ducts, building entrances, metro routes or submarine systems for any individual customer circuit.
- Buyers should treat generator endurance, fuel contracts, actual dual-substation separation, cooling performance at full load, cross-city replication, sold capacity, PUE, incident history and recovery results as unknown until Omni supplies asset-specific evidence.
Two sites, two very different evidence packages
PT Omni Data Center Indonesia is not merely a name inferred from an old routing record. The Asia Pacific Network Information Centre's registration data assigns the company two active autonomous system numbers, AS152774 and AS56868, as well as the IPv4 block 202.47.170.0/23 and IPv6 block 2401:a320::/32. The APNIC record for AS152774 describes the holder as a corporate or direct IDNIC member and data-centre provider at Jalan Kampung Belian No. 3 in Batam. The APJII membership directory independently lists PT Omni Data Center Indonesia, the OMNIDATACENTER trading name, the same No. 3 address and the omnidc.co.id domain.
The operational story uses a different nearby address. Omni's current website places BTM1 at Jalan Perahu Dendang No. 1, Batam Center, and JKT1 in the Cyber 1 Building on Jalan Kuningan Barat Raya No. 9B in South Jakarta. That is not necessarily a contradiction: a registered office can differ from the building where servers run. It does mean that corporate registration, IP-resource registration and facility ownership should not be collapsed into one claim.
The group boundary matters too. Solnet's corporate history says PT Solnet Indonesia acquired land in Batam in 2019 and began a seven-storey building, with two floors intended for a Tier 3, 2MW data centre. It says the building was completed and brought into use in April 2023, and that PT Omni Data Center Indonesia began developing a Tier 3 data centre that August. Omni later described itself as part of Solnet Group. This is useful provenance for the Batam building and the operating ecosystem, but it does not reveal which legal entity owns the land, building, electrical plant, cooling equipment or customer contracts today. Nor does it establish that the original 2MW concept became 2MW of installed or sellable IT capacity.
The newest Omni product sheet narrows that ambition. The one-page BTM1 facility specification states 680 m2 of phase-one colocation space and "2N (1.2 MW of IT Load dual Source)." That is a site-specific number and is therefore more useful than the older group milestone. Yet the sheet does not say how much of 1.2MW was installed, commissioned, energised, occupied, reserved or available on 15 July 2026. It also does not publish the load at which cooling and generator systems have been integrated-tested.
JKT1 has a different pattern. Omni announced the site as inaugurated in October 2025. Its JKT1 and BTM1 brochure gives the Jakarta phase-one area as 864 m2, a floor-loading range of 600 to 1,200 kg/m2 and default rack power of 2.2kW, upgradeable to 32 amps or three phase. It publishes component-topology labels but no total IT-load number. Area is not capacity: an 864 m2 room could support very different rack counts and usable power depending on white-space layout, structural constraints, cooling density, electrical reservations and operating margin.
The result is not an absence of evidence. It is evidence of two unequal propositions. BTM1 has a marketed IT-load figure without a public third-party constructed-facility award. JKT1 has an independent design-document award without a published total IT-load figure or a public constructed-facility award. A procurement team should preserve that distinction all the way into the contract.
The second-floor certificate and the fifth-floor address
JKT1's exact physical boundary deserves special attention. Omni's own brochure gives Cyber 1 Building, second floor. The Uptime Institute's Indonesia award directory likewise names "OMNI DC JKT1, IT Hall 1, 2nd Floor" and lists Tier III Certification of Design Documents. Omni's website sometimes calls the location a Jakarta office and also places it on the second floor.
PeeringDB's OMNIDC JAKARTA facility entry, however, records "Cyber 1 Building, 5th Fl" and identifies PT Omni Data Center Indonesia as the facility organisation. Solnet's own site also places its Jakarta centre on the fifth floor. The most plausible reading is that the group has activity on more than one floor, or that office, point-of-presence and IT-hall records refer to different spaces. That is an inference, not a verified floor plan. The public material does not settle whether every network shown at the PeeringDB facility is physically present in Omni's second-floor hall, the fifth-floor group space, another Cyber 1 meet-me room, or reachable over an extended exchange fabric.
This is not pedantry. A customer buying two supposedly diverse cross-connects needs to know the room, riser and meet-me-room path for each. A customer buying disaster recovery needs to know which floor contains the contracted racks, which entity controls access, and where shared building systems create common failure points. The relevant evidence would be a signed site schedule, rack and room identifiers, demarcation diagrams, building riser drawings and a walk-through. A web address is only a locator.
Cyber 1 also has a material history. A fire in the building on 2 December 2021, years before JKT1's launch, caused shutdowns that affected Indonesia's mobile-device identity registration process. ANTARA's report relayed the communications ministry's account and reported two deaths. That incident does not show that Omni's later hall failed, or even existed at the time. It does show why building-level fire zoning, smoke migration, emergency power isolation and evacuation procedures matter even when a tenant's own room has suppression equipment.
Omni says JKT1 uses FM-200 suppression and monitors smoke, fire, water, temperature, humidity and electrical conditions. Those are relevant controls. Public material does not disclose the commissioning date of each control, inspection records, cause-and-effect tests, separation from other tenants, or what happens to cooling and customer power when the building management orders a broader shutdown. A serious customer should ask for those records rather than treating the words "fire suppression" as the end of the fire analysis.
What the Tier III award does, and does not, establish
Omni announced in January 2026 that it had received Tier III Design certification. The company's certification article accurately uses the word "Design" and says the certificate was received in November 2025. The independent award directory supplies the missing scope: JKT1, IT Hall 1, second floor.
That scope is important because Tier language is frequently used as if it were a blanket operating guarantee. Uptime's own award terms say a Tier Certification of Design Documents is a formal review of a specific facility design and intended implementation, including its phase and expected capacity. The same terms say a Tier Certification of Constructed Facility reviews installed infrastructure and performance demonstration tests during a site visit. Design awards issued after 1 January 2014 expire after two years.
Uptime puts the distinction even more plainly in its explanation of design and constructed certification: design review shows what a project should deliver on paper if faithfully built, while as-built performance can differ. A separate Uptime discussion of Tier misconceptions says component labels such as N+1 and 2N do not by themselves determine a Tier level because distribution paths and system configuration matter.
As of 15 July 2026, the public Indonesia directory showed only the design-document award for Omni. It did not show a Constructed Facility award or Operational Sustainability award for JKT1, and it did not show an Omni BTM1 award. This is a bounded observation of the public directory, not a claim that Omni could not have testing, commissioning or other certificates in a customer data room. It means buyers should describe the public credential exactly: a scoped JKT1 design certification.
The same discipline applies to ISO/IEC 27001. Omni says it is certified, and its older Batam launch material specifies ISO/IEC 27001:2022. The ISO description of the standard explains that it sets requirements for an information security management system. That is valuable, but it is not an electrical-availability test, a cooling-capacity test, a fire-system acceptance test or proof that two carrier routes avoid a common duct. A buyer should obtain the actual certificate, issuing body, validity dates and statement of applicability to see which company, sites and activities are in scope.
Batam power: a number is not a delivery path
BTM1's brochure contains unusually useful detail for a small provider. It states a PLN utility feeder, 2N electrical configuration with 2N transformers, 2N active-active UPS, a 2N lithium battery system with 15 minutes of backup, N+1 standby generation, N+1 cooling, and 2N transformer, cubicle and power rooms. Omni's home page summarises this as "2N power from dual substations." PeeringDB's Batam facility record marks diverse serving substations as yes and available service voltage as 400VAC.
These statements describe intended topology. They do not yet disclose the topology's independence. Two utility feeds can still share an upstream substation, transmission corridor, switchgear room, protection scheme or building entry. Two substations can share a regional grid event. Two UPS paths can converge at a rack PDU. An N+1 generator set can fail to carry the full contracted load if fuel, starting batteries, cooling, exhaust, switchgear or maintenance state is unfavourable. The phrase "dual source" therefore needs a single-line diagram and test evidence behind it.
The regional grid had measurable headroom at the end of 2025. PLN Batam reported 812MW of net dependable capability, a 2025 peak of 741MW and 71MW of reserve. That is reassuring context for Batam-Bintan as a system. It does not prove that BTM1 has 1.2MW of firm connection capacity at its exact point of delivery, or that both feeds can each carry the site's critical load when one path is unavailable.
Other Batam projects illustrate what project-specific power evidence looks like. In October 2025, PLN Batam published a power-purchase agreement for up to 90MVA of medium-voltage premium service to another data-centre developer, phased from 2025 to 2028. In April 2026, BP Batam described a separate 511MVA agreement for a large campus and linked it to fibre and maintenance studies. Those announcements do not apply to Omni. They demonstrate the difference between broad regional supply and a named, contracted facility connection.
No equivalent public utility agreement for BTM1 was located in the material reviewed for this article. Absence from public search is not proof that no agreement exists. It means BTM1's customer should ask for the connection agreement or a redacted utility confirmation showing contracted capacity, voltage, feeder names, substation sources, firm-versus-interruptible terms and restoration priority.
The 15-minute battery figure also needs careful interpretation. Battery autonomy is normally load-dependent and changes with ageing, temperature and discharge assumptions. Fifteen minutes may be ample to bridge a healthy generator start and transfer sequence; it is not 15 minutes of guaranteed customer service under every load or maintenance condition. The missing facts are the test load, battery age, end voltage, concurrent failure assumptions, generator start time, failed-start sequence and most recent discharge-test result.
Generator endurance is entirely undisclosed. The brochure says N+1 at Batam and 2N at Jakarta, but gives no engine rating, on-site fuel volume, runtime at critical load, replenishment contract, flood exposure, emissions limits or refuelling priority during a prolonged grid emergency. For a customer, "has generators" and "can sustain service through a long outage" are different propositions.
Cooling, rack density and usable capacity
Power delivered to the building is only the first capacity gate. The BTM1 sheet gives default rack power as 10 amps or 2.2kW, with upgrades to 32 amps or three-phase service. It gives a temperature range of 22 C plus or minus 4 C, relative humidity of 55% plus or minus 10%, and cold-aisle containment. JKT1 publishes the same default rack offer, 2N+1 cooling and 2N UPS.
Those figures do not reveal the number of racks, the share configured above 2.2kW, the average and maximum supported density, or whether every part of the phase-one floor can be cooled at the maximum electrical allocation. A nominal 1.2MW IT load divided by 2.2kW would imply more than 500 default-density racks, but that arithmetic must not be mistaken for installed capacity. A facility with 680 m2 of colocation space may allocate substantial area to aisles, cages, meet-me rooms, staging and safety clearances. Rack count and usable kilowatts must come from the actual fit-out schedule.
Nor does the public evidence show PUE, water usage, chiller arrangement, refrigerant inventory, heat-rejection topology or high-density capability. Marketing language on AI, edge and cloud use cases does not establish that the rooms can host direct-to-chip cooling, rear-door heat exchangers or sustained high-density air cooling. Buyers considering GPU clusters should request a rack-density map, supply-air design conditions, hydraulic or refrigerant redundancy, derating rules, and an integrated test at the proposed load.
Sold and reserved capacity is also unknown. A capacity figure can be design capacity, installed capacity, commissioned capacity, powered capacity, operational capacity or capacity available for a new order. Omni does not publicly break 1.2MW into those states. It does not publish contracted occupancy, expansion timing or inventory by hall. The only safe public statement is that the company markets a 1.2MW phase-one Batam configuration and a phase-one Jakarta area of 864 m2.
This is where service-level language can mislead. Both brochures state an SLA of 99.982%, equivalent to roughly 94.6 minutes of annual unavailability if applied continuously across a non-leap year. The documents do not show the contract definition of availability, excluded maintenance, force majeure, measurement point, credit cap or whether power, cooling and network are measured separately. A percentage without its denominator and exclusions is not a recovery plan.
The network evidence is real, but mostly logical
Omni's strongest externally observable operating evidence is its interconnection footprint. PeeringDB's organisation record lists the Batam and Jakarta facilities, two company-associated networks and OMNIIX. On 15 July 2026, the Batam facility showed 13 networks and one local exchange; Jakarta showed 18 networks and one local exchange. The counts are self-maintained ecosystem records rather than an audit, but named third-party networks choosing to list a facility are more informative than a marketing adjective.
OMNIIX itself had a wider footprint. The exchange record showed 30 entities and nine listed facilities across Batam, Jakarta, Surabaya and Pekanbaru. The facility set included BTM1 and JKT1 alongside third-party data centres. This supports the existence of a distributed exchange service. It also shows why a network appearing on OMNIIX cannot automatically be counted as physically cabled into either Omni building. An exchange member can connect at another enabled facility and reach the shared fabric logically.
AS56868 is explicitly labelled as the OMNIIX route server. Its PeeringDB network entry showed a 10Gbps operational port, IPv4 and IPv6 exchange addresses, both Omni facilities and a reported traffic band of 50-100Gbps. The exchange notes say the ASN is used exclusively for route servers, with no transit or customer traffic. That is a meaningful control-plane role, but it is not an upstream transit map for Omni's colocation customers.
Public route observation fits that role. The RIPEstat routing view for AS56868 showed no currently announced global prefixes from the ASN on 15 July 2026. The view for AS152774 also showed none, and PeeringDB showed no exchange or facility connections for that network. Meanwhile, APNIC marks both ASNs active and registers 202.47.170.0/23 to Omni, but the RIPEstat prefix view showed the block as not globally announced.
These observations should not be described as a network outage. A route-server ASN does not need to originate public customer prefixes, and private exchange LAN addresses should not appear in the global table. The evidence instead sets a limit: the public BGP table cannot prove Omni's transit diversity, customer route availability or failover behaviour. Those require looking glasses, route-server configuration, customer-specific upstreams, route-policy documents and controlled failover tests.
The IPv4 exchange addresses add another ownership nuance. APNIC registration for 43.255.58.0/24 identifies PT Solnet Indonesia, while Omni's IPv6 exchange block 2401:a320::/32 is registered to PT Omni Data Center Indonesia. Shared group infrastructure is plausible, but the records do not show the commercial and operational handoff between the two companies. A customer should know whether Omni, Solnet or another carrier is responsible for each port, address, cross-connect and incident response.
Carrier neutrality does not prove route diversity
Omni repeatedly describes both sites as carrier neutral. Its BTM1 sheet claims four diverse fibre paths entering the site through multiple risers, two meet-me rooms, access to several internet exchanges, dark fibre and metro connectivity to Batam and Jakarta data centres, and connectivity to submarine landing stations. The JKT1 sheet similarly lists direct carrier access, remote peering and a long set of exchange and operator names.
This is a commercially useful menu, not a route survey. Four entrances can converge in the same street duct. Multiple carriers can lease fibres in one cable. Two cross-connects can terminate on the same provider chassis. A remote-peering product can present many logical destinations through one physical access circuit. A list that includes Singapore exchanges does not prove that a customer's path crosses a particular submarine cable, much less two cables with independent landing stations and marine routes.
Batam does have genuine cable geography. The long-running Batam-Singapore Cable System connects Batam Centre and Changi, while newer projects have added or proposed more direct data-centre connectivity. BW Digital describes a 50km, 24-fibre-pair Nongsa-Changi system landing directly at its own Nongsa campus. TeleGeography's Submarine Cable Map entry for Hawaiki Nui 1 lists Batam as a planned landing point with a 2027 ready-for-service date. Those facts establish Batam's regional relevance, not BTM1's entitlement to those systems.
BTM1 is in Batam Center, not at Nongsa Digital Park. Omni says it can reach landing stations by dark fibre and metro services, but it does not publish carrier names, cable-system names, exact routes, duct ownership, handoff facilities or service status. A line from Batam to Singapore on a sales map could represent a purchased wavelength, remote-peering service or logical reach. It cannot be read as proof that Omni owns or directly lands a submarine cable.
For a genuinely diverse design, the customer needs route evidence at several layers: separate building entrances; separate metro ducts; separate carrier equipment; separate terrestrial routes to distinct cable landing stations; separate submarine systems where cross-border continuity matters; and route-policy diversity beyond the landing points. The test must continue through every common exchange, power room and remote-peering platform. "Multi-carrier" answers a choice question. It does not answer a common-mode-failure question.
IIX collaboration proves participation, not every performance claim
Omni's relationship with APJII is more than a vague association. The company's account of the August 2024 agreement says the parties introduced an Indonesia Internet Exchange node at BTM1. The APJII membership directory confirms Omni as a corporate member. PeeringDB confirms an active exchange fabric and named entities. Together, these records support the conclusion that Omni is participating in Indonesia's interconnection ecosystem.
They do not establish that APJII guarantees BTM1's entire network, that every OMNIIX entity peers with every other entity, or that the exchange offers physically separate paths between Jakarta and Batam. Peering policies, bilateral sessions, route-server sessions and transport contracts remain distinct. Even the PeeringDB speed field is a declared port capacity, not a continuous throughput measurement or a commitment available to every customer.
The APJII listing does not state a licence type for Omni. Omni's JKT1 brochure says the data centre operates with a Network Access Point licence, while Solnet's history says Solnet obtained such a licence in 2020. These records can coexist if JKT1 relies on a group licence or licensed affiliate, but the public evidence does not establish the legal arrangement. Customers purchasing a regulated connectivity service should request the licence number, holder, scope, validity and contractual chain. A colocation provider's corporate membership is not itself a telecom licence.
Dual-site is an architecture option, not a recovery result
Omni markets Jakarta and Batam as a dual-site platform for business continuity and disaster recovery. The two cities are geographically separated, and using both can reduce exposure to a single building incident. That is a real architectural option. It does not automatically create a resilient service.
The customer's applications must replicate between sites, preserve data consistency, handle split-brain conditions, manage DNS or routing changes, and operate within an acceptable recovery point and recovery time. The transport must have enough capacity and must avoid common paths. Staff, credentials, monitoring, backups and suppliers must remain available during the same event. None of those outcomes follows merely from renting racks in two cities.
There is also no public customer case study showing a live workload failing from JKT1 to BTM1 or the reverse. No recovery-time result, recovered data point, replication bandwidth, maintenance exercise or post-incident report is published. The company may possess such evidence privately. Until it is supplied, "dual-site" should be read as two places where a design can be implemented, not as proof that an implemented design has recovered successfully.
Distance creates its own trade-off. Batam can offer proximity to Singapore and diverse regional connectivity, while Jakarta places workloads near Indonesia's principal business and network concentration. The inter-site path adds latency and dependency on metro, long-haul and potentially submarine infrastructure. Synchronous replication may be feasible for some workloads and unsuitable for others. The customer, not the facility brochure, must set the recovery objective and test the full application path.
Five failure chains expose what the component labels leave out
The most productive way to assess Omni is not to count how many times a brochure says 2N. It is to trace a small set of plausible failures from initiating event to customer impact. Each chain crosses commercial and technical boundaries, which is precisely why a component inventory cannot settle it.
The first chain begins with loss of utility supply at BTM1. If the two feeds are genuinely sourced from independent substations and each can carry critical load, one feeder fault should not interrupt the UPS input. If a wider event removes both feeds, the batteries must hold the load while standby generation starts, synchronises and accepts it. At that point, availability depends on protection settings, automatic transfer logic, starter systems, fuel, ventilation and operator response. If one generator is already in maintenance, the meaning of N+1 depends on the remaining installed capacity and current IT load.
Customers whose equipment has dual power supplies also need their A and B rack paths to remain separate through PDUs, busways, UPS modules and switchboards. A single diagram could reveal more than several availability slogans.
Who is affected depends on the point of convergence. A transformer fault upstream of genuinely separate paths may have little effect. A bus fault after the paths merge can remove an entire room. A faulty rack PDU can affect one cabinet. A protection miscoordination can turn a local fault into a larger trip. The public material does not show selective-coordination studies, transfer-test results or the load carried during the last generator exercise. Those are the records that would show whether the 1.2MW design behaves as intended.
The second chain begins with cooling loss. Omni publishes N+1 cooling for BTM1 and 2N+1 for JKT1, but neither label identifies the redundant unit, distribution path or heat-rejection dependency. Loss of one computer-room cooling unit might be benign at low occupancy. Loss of common chilled-water pumps, controls, condenser power or outside heat rejection can affect every nominally redundant indoor unit. Temperature rises faster in a high-density rack than in a lightly loaded room, so usable recovery time varies with actual deployment.
Customers need trend data and a witnessed failure test at representative load, not just a design temperature band.
A cooling incident may not cause an immediate hard outage. Servers can throttle, error rates can rise, fans can consume more power, and operators may shut down selected racks to preserve the room. That is why an availability definition limited to electrical power can miss degraded compute service. The SLA should say whether environmental excursions count, where temperature is measured and how long it may remain out of range before a service breach is recognised.
The third chain begins with smoke or fire in a rack, electrical room or another Cyber 1 tenancy. Detection must identify the zone; suppression and power isolation must contain it; smoke control must protect people and equipment; and emergency decisions must account for shared building systems. The 2021 Cyber 1 event demonstrates that an incident in a multi-tenant building can interrupt services beyond the room where it began. It does not predict JKT1's current performance, but it makes the building interface a first-order diligence item.
For JKT1, customers should ask whether the certified second-floor hall has independent fire compartments, how smoke can travel through risers and air systems, which party can order an emergency shutdown, and whether generator, UPS and cooling plant are on the same floor or elsewhere in the building. They should also ask how an evacuation affects remote hands and how long unmanned operation can continue. A room-level suppression system cannot by itself guarantee building access, cooling, utility continuity or staff availability after an incident.
The fourth chain begins with a carrier-meet interruption. A fibre cut outside BTM1 could remove several providers if their cables share the same duct. A meet-me-room power issue could disrupt otherwise separate outside routes. A failure on the transport used to extend OMNIIX between facilities could reduce access for remote entities without damaging either Omni building. A route-server problem could affect networks that depend on it, while bilateral sessions continue. Each event has a different blast radius, and none can be inferred from the total number of exchange entities.
The customer test should therefore disable one physical path at a time and observe routing, session state, traffic loss and recovery. It should identify which services depend on AS56868's route servers, which use bilateral peering, which use paid transit and which are carried over private waves. The result should include convergence time and any manual steps. A topology can be multi-upstream in BGP while all upstreams ride one metro cable; conversely, two physical paths can still fail to provide service if routing policy does not move traffic correctly.
The fifth chain begins during planned maintenance. Tier III's central promise is concurrent maintainability at the certified topology level, but the public Omni award covers JKT1 design documents rather than a witnessed as-built demonstration. A maintenance exercise should show that a transformer, UPS module, switchboard section, generator or cooling unit can be isolated without exposing the critical load to an unplanned single point of failure. The method of procedure, rollback point, staffing and change freeze are as important as the equipment count.
Maintenance is also where ownership boundaries become operational. Building management may control a utility shutdown. Solnet may operate a network or licensed service. Omni may control the hall and customer contract. A carrier may own the cross-connect beyond the demarcation. If the parties use different notification windows or escalation trees, a technically redundant design can still produce avoidable downtime. Contract schedules should align those parties before the first maintenance event, not after an incident.
These five chains lead to a common conclusion. Power, cooling, fire protection, network reach and maintenance are not separate marketing features once a workload is live. They are a sequence of dependencies. The relevant unit of resilience is the customer's end-to-end service, including the physical rack, both power paths, environmental control, every required network path, remote access and the people authorised to restore it.
Maps can locate assets, but cannot certify the route between them
Public geographic evidence is strong enough to locate the service at city and building level. The Batam facility is consistently associated with Jalan Perahu Dendang No. 1 in Batam Center, while corporate records use nearby Jalan Kampung Belian No. 3. JKT1 is consistently associated with Cyber 1 at Jalan Kuningan Barat Raya No. 9B, even though the public floor references differ. PeeringDB publishes coordinates for the Jakarta facility, but its Batam facility entry does not publish coordinates; the organisation record geocodes the Batam group address. That level of precision can guide a site visit, not an engineering conclusion.
None of the reviewed public records supplies surveyed fibre routes. Omni's phrase "four diverse fibre paths" does not identify road crossings, bridges, ducts, poles, chambers or landing stations. PeeringDB's nine OMNIIX facilities show places where the exchange can be reached, but not the transport geometry connecting them. Submarine cable maps show system landing points and broad marine paths; they do not show the private metro tail from BTM1 to a landing station or whether two purchased services share that tail.
The same limit applies to hazards. A city-level flood or storm map cannot establish the elevation of electrical rooms, fuel tanks, fibre chambers or basement plant. A building coordinate cannot show fire compartments. A straight line between Batam and Jakarta cannot show cable ownership, repair exposure or intermediate dependencies. Asset-specific resilience needs surveyed drawings, site inspection, route letters from carriers and, where necessary, geographic separation clauses in the service contract.
For that reason, no exact physical route should be reconstructed from Omni's marketing material. The defensible map has two facility points, a set of independently listed exchange locations and region-level cable landing context. Everything between those points remains unverified until carriers disclose it.
Operating status: enough to reject "paper project," not enough to measure load
Several independent signals support current operations. PeeringDB created the Batam facility record in June 2024 and the Jakarta facility record in June 2025; both now list third-party networks. The Uptime directory records a scoped Jakarta design award. The company announced JKT1's inauguration in October 2025. An ISEAS - Yusof Ishak Institute report published in late 2025 classifies Omni DC as an extra-small Batam data centre in operation.
That last report is useful but not definitive. Its annex says it drew on industry directories and news sources, and "extra small" is not tied there to a disclosed megawatt threshold. Commercial directory Data Center Map also lists the Batam site, rack options and remote hands, but much of its technical description resembles operator-provided material. These are corroborating market signals, not commissioning certificates.
The evidence is sufficient to say Omni has more than a proposed website: it has registered network resources, an active exchange operation, listed facilities, named third-party networks and an inaugurated Jakarta hall. It is not sufficient to calculate live IT load, customer count, occupancy, delivered uptime or available megawatts. Those numbers remain unknown.
What a buyer should verify before treating the two sites as one resilient platform
The right diligence exercise is asset-specific. For BTM1, the customer should request proof that the contracted rack sits inside the 680 m2 phase-one area and that its allocated kilowatts are included in commissioned capacity. The evidence should include an electrical single-line diagram, utility connection letter, transformer and switchgear ratings, UPS module inventory, battery discharge tests, generator load-bank tests, cooling commissioning results and the most recent integrated systems test.
For JKT1, the contract should name the floor, hall, rack, demarcation point and operating entity. The customer should obtain the Uptime certificate itself and verify the award date and exact scope. If Omni represents the facility as constructed-certified, it should supply the corresponding Uptime listing or certificate; the public directory reviewed here does not provide one. The buyer should also obtain building fire-safety records, room boundaries, riser paths and the response procedure for smoke or fire elsewhere in Cyber 1.
For network resilience, a carrier list is only the start. Each proposed circuit should be documented from the rack to its far endpoint. The documentation should identify cross-connect owner, meet-me room, building entrance, street duct, metro provider, long-haul provider, cable landing station and submarine system where relevant. The two circuits should be compared for shared structures and suppliers. OMNIIX membership and remote-peering reach should be shown separately from paid transit and private transport.
For operational resilience, the customer should review staffing rosters, escalation paths, spares, maintenance windows, incident communications, fuel replenishment, security access and recovery exercises. It should ask for anonymised service history with the availability formula used in customer SLAs. A claimed 99.982% target becomes meaningful only when exclusions, credits and measurement points are visible.
Finally, the legal schedule should assign responsibility among PT Omni Data Center Indonesia, PT Solnet Indonesia, building management, utilities and carriers. It should identify who owns or leases the relevant space and plant, who holds any required connectivity licence, who invoices each service and who is accountable when a shared component fails. Group affiliation can strengthen delivery, but only a clear contract prevents it from blurring accountability.
A credible small platform, with proof still uneven by layer
PT Omni Data Center Indonesia has assembled a credible small-platform proposition around a real Batam facility, a newer Jakarta hall and a growing exchange fabric. BTM1's disclosed 1.2MW IT-load figure, 680 m2 phase-one room and detailed component claims give customers something concrete to interrogate. JKT1's 864 m2 phase-one area, 2025 inauguration and Uptime design-document award give the second site more substance than a simple planned location. PeeringDB participation shows that networks are using the ecosystem.
But the public record does not support one undifferentiated claim of Tier III, 2N power and diverse connectivity across everything Omni sells. The independent Tier III record is scoped to JKT1's design documents and second-floor IT Hall 1. The Batam power number is operator-published. The fifth-floor PeeringDB address does not line up neatly with the second-floor certified hall. Regional grid reserve does not prove site delivery. Thirty exchange entities do not prove 30 physical carriers at either building. Four claimed fibre entrances do not reveal four independent end-to-end routes.
That unevenness is not a reason to dismiss Omni. It is a reason to buy precisely. The company has enough external operating evidence to merit serious diligence, but not enough public engineering and service data to let a customer skip it. The decisive question is no longer whether Omni exists. It is whether the exact rack, kilowatt and path being sold can survive the failures the customer's service cannot afford.

