Your Servers Are in Tseung Kwan O. Who Actually Goes to the Cage?

Short answer: Colocation in Hong Kong buys you power, cooling, connectivity and physical security. It does not buy you hands, eyes, spare parts, change records or a 3am escalation path. Those five jobs inside the cage belong to somebody — and in most small trading firms, they belong to nobody in particular until the night they matter.

A Hong Kong brokerage signed a colocation contract in Tseung Kwan O, moved two racks of trading and market-data infrastructure in, and ran cleanly for eighteen months. Then a redundant power supply failed on a Sunday, the standby did not take over cleanly, and the head of technology discovered — while standing in a taxi queue in Wan Chai at 11pm — that nobody in the firm had a documented answer to a simple question: who actually goes to the cage?

This is an illustrative composite scenario, not a named client. It is grounded in real Brocent project work at Hong Kong's Equinix IBX facility and in real service lines described below. No pricing figures, statistics or client names have been invented, and this article deliberately quotes no per-rack or per-kW colocation prices — those vary by facility, contract and power density to a degree that makes any published number misleading.

What does colocation in Hong Kong actually leave you responsible for?

Colocation is often described as "renting space in a data centre." That framing is accurate and unhelpful, because it hides the boundary that matters.

What the facility provides is genuinely excellent and genuinely narrow: conditioned power with redundancy, cooling within specification, physical security and access control, fire suppression, structured connectivity to carriers and exchanges, and a building that stays standing during a typhoon. In Hong Kong specifically, you are also buying proximity — to counterparties, to exchange infrastructure, to the carrier meet-me rooms that make low-latency connectivity possible.

What the facility does not provide is the operation of your equipment. Inside your cage, the racks are yours, the servers are yours, the switches are yours, the cabling is yours, the firmware versions are yours, the asset register is yours, and the failure at 3am is yours.

Most colocation providers will sell you some form of "remote hands" — an on-duty technician who will, within an SLA, perform a defined set of physical actions on request. This is a real and useful service. It is also frequently misunderstood as a substitute for operational ownership, which it is not, for reasons we will get into.

The scenario: two racks, eleven kilometres, and nobody whose job it is

Picture a Hong Kong SFC-licensed brokerage of around sixty staff — a mix of proprietary trading and agency execution for institutional clients. Front office in Central. Two racks in a Tseung Kwan O facility holding order-management and execution servers, market-data feed handlers, a pair of firewalls, top-of-rack switches, a small storage array, and the cross-connects to their brokers and market-data vendors.

The technology team is four people. A head of technology who came from a trading background, two developers who maintain the in-house execution logic, and one systems person who does everything else — endpoints, Microsoft 365, the office network, vendor management, and the data centre.

That systems person has been to the cage eleven times in two years. Each visit was unplanned. Each visit consumed a full day, because Tseung Kwan O is not somewhere you drop into between meetings. And each visit was, in the moment, the single highest-priority thing happening in the firm.

Nothing about this is negligent. It is the completely rational outcome of a firm that grew past the point where one person could cover both the office and the cage, without anyone noticing the moment it happened. The failure mode is not incompetence; it is that the cage has no owner, only a volunteer.

The five jobs inside a cage that nobody owns by default

Hands: physical intervention, at speed, correctly

The obvious one. Someone has to reseat a drive, swap a failed PSU, re-cable a port, power-cycle a device that has stopped responding to its management interface, or physically confirm which of two identically-labelled boxes is actually the one that failed.

Facility remote hands can do much of this, and for a straightforward "power-cycle the device in U14" request, it is exactly the right tool — fast, already onsite, no travel time. Where it gets thinner is when the task requires judgment about your environment rather than execution of a described action. A remote-hands technician working from a ticket does not know that your secondary feed handler must never be started before the primary has fully caught up, because that is not written anywhere they can see it.

Eyes: noticing what the facility's monitoring does not cover

The data centre monitors its own infrastructure — power draw, temperature, humidity, access events. It does not monitor whether your RAID array has been running degraded for six weeks, whether a redundant PSU has quietly failed leaving you single-corded, whether a fan has died, or whether your switch has been logging CRC errors on an uplink since a cable was disturbed during someone else's install.

This is the failure class that turns a non-event into an outage. Redundancy failures are silent by definition — the whole point of redundancy is that the service keeps running. If nobody is watching for the loss of redundancy, you find out about the first failure at the same moment as the second.

Brocent's approach here is straightforward: IT hardware maintenance is built around a 24×7 NOC whose monitoring systems sense infrastructure health and trigger warnings to the NOC team for immediate response, backed by Tier III backline engineers holding CCIE and CISSP certifications who troubleshoot and advise on remediation. The point of the NOC is not that it watches harder than you would; it is that it watches continuously, which no four-person technology team can.

Parts: spares, warranty, and the RMA that takes eleven days

When a component fails, the question is not "can it be replaced" but "how quickly can the right part be in the right building." A next-business-day warranty from the original manufacturer is a fine thing on a Tuesday morning and considerably less useful at 2am on a public holiday.

There are three practical answers, and firms usually pick one by accident rather than deliberately. Keep cold spares in the cage — cheap for switches, expensive and awkward for servers, and only useful if somebody can install them. Rely on manufacturer warranty — clean, contractual, and paced to the manufacturer's convenience rather than yours. Or contract multi-vendor third-party maintenance, where the provider holds stock. Brocent runs the third model: warehouses in twelve countries stocking hardware and spare parts, system-tracked, covering HPE, IBM, Cisco, Dell/EMC, Juniper, Palo Alto, Fortinet, NetApp, Aruba, Lenovo, Polycom and most mainstream manufacturers under a single third-party maintenance contract, with in-country spare parts held in Hong Kong, mainland China, Japan and Singapore.

Paper: the asset register, change records and decommission evidence

This is the job that feels least urgent and causes the most trouble later. For an SFC-licensed firm in particular, the ability to state confidently what is in the rack, what changed, when, who authorised it, and what happened to the equipment that was removed, is not administrative tidiness — it is the evidence base that any operational-resilience conversation with a regulator, an auditor, or a cyber-insurer will start from.

The uncomfortable truth is that cage documentation decays fastest precisely when the cage is busiest. The single most valuable artefact a firm can have is a current rack elevation with serial numbers, and the single most common finding when we walk into an unmanaged cage is that the last accurate one is three years old.

Escalation: who gets out of bed, and what are they authorised to do

The final job is the one that only exists at 3am. Who is called? What can they decide alone? Can they authorise a facility technician to power down a device? Is there a documented runbook for the four or five failure modes that actually threaten the trading day, or is there a person who remembers most of it?

An escalation path that lives in one person's head is not an escalation path. It is a single point of failure wearing a job title.

Facility remote hands, MSP field engineers, or a dedicated onsite body?

The three models compared

• Facility remote hands: Fastest possible physical response, because the technician is already in the building. Priced per incident or per block of time. Best for simple, precisely-describable actions — power-cycle, reseat, swap a labelled part, take a photo of a status light. Weakest where the task needs environment-specific judgment, because the technician is deliberately generic: they support every tenant in the building and cannot know your system dependencies.
• MSP field engineers under a maintenance contract: Slower to arrive than someone already onsite, but they arrive knowing your environment, carrying your spare, and with the authority and documentation to complete the work end to end. This is the model that covers the "eyes," "parts" and "paper" jobs as well as the "hands" job, because it is a continuing relationship rather than a per-incident transaction. Brocent's field-service and infrastructure deployment teams work exactly this way, with regional certified engineers, offsite staging, and structured rack-and-stack project management.
• Your own dedicated onsite person: Full control and full context, and the right answer above a certain scale. Below that scale it is an expensive way to buy availability, because the work is bursty — long quiet periods punctuated by intense days — and one person cannot cover 24×7 anyway. A full-time onsite engineer from a provider is a middle path: a dedicated named individual, but with leave cover and an escalation network behind them.

In practice the right answer for a sixty-person brokerage with two racks is almost always a combination: facility remote hands for the trivial and immediate, a maintenance contract for everything requiring parts, judgment or documentation, and a clear written rule about which is which.

What actually decides between them

• How reversible is a mistake? Power-cycling the wrong device in a trading environment is not a small error. The more consequential the physical action, the more you want somebody who knows your system rather than somebody following a ticket.
• Does the task need a part? If yes, the question collapses into logistics: who holds the spare, and how far away is it?
• Does the task generate evidence you will need later? Decommissioning, disposal, and any change touching a regulated system need a documented chain — which is a contract-shaped requirement, not a remote-hands-shaped one.

How Brocent thinks about cage operations

Grounded in real work: the Equinix IBX project

Brocent's view of this is not theoretical. One of our data-centre projects was a rack-and-stack and decommission programme for a financial services client at Hong Kong's Equinix IBX facility: decommissioning 37 HP DL380 units and HP switches, racking and stacking new Cisco UCS, an ISR 4329 firewall and Nexus 5624Q switches, providing certified data-destruction certificates as part of the ITAD process, and delivering a function-testing and commissioning report at the end. The whole programme was executed across six weekend days specifically to avoid disrupting the client's business.

Several things in that description are the actual lesson, and they are easy to skim past.

It was scheduled across weekends. Not because weekend work is glamorous but because for a financial client the cost of a weekday change window is measured in trading, not in engineering hours. Cage work should be planned around the business calendar as a first-order constraint, not fitted in afterwards.

The old equipment produced certificates, not just an empty rack. Certified data destruction on decommissioned units is the difference between "we removed the servers" and "we can evidence what happened to every drive." For a regulated firm this is the part that matters years later.

There was a commissioning report. Function testing and a written report at handover is what converts a physical installation into a documented state you can reason about. Without it, the asset register starts decaying on day one.

The operating principle: separate what is urgent from what is judgment

Our working rule for colocated infrastructure is that speed and judgment should be sourced differently. Anything where the correct action is fully describable in advance should be handed to whoever is physically closest, which usually means facility remote hands, and should be pre-authorised so that no one has to make a decision at 3am about whether they are allowed to ask.

Anything where the correct action depends on knowing the environment should be handled by engineers who hold that context continuously — which means it has to be a standing relationship with documented environment knowledge, not a call-out.

Most cage incidents that turn into outages are cases where the first category was handled slowly because nobody was pre-authorised, or the second category was handled fast by somebody without context.

Build the runbook before you need it

The single highest-return piece of work for a firm in this position takes about two days and no capital expenditure.

Produce a current rack elevation with every device, its serial number, its position, its power feeds and its cross-connects. Write down the four or five failure modes that would actually threaten a trading day, and for each one, the first three actions and who is authorised to take them. Pre-authorise the facility's remote-hands service for a defined list of safe physical actions, in writing, so that authorisation is not a 3am conversation. Establish where each class of spare lives and how long it takes to arrive. And record who is called, in what order, with a real phone number rather than a distribution list.

That document is worth more than an upgraded SLA, and almost nobody has one.

What drives the cost of cage operations

We are not going to publish per-rack or per-kilowatt colocation prices here. They vary too much by facility, contract term, power density and connectivity mix for a published number to be anything other than misleading, and Hong Kong in particular has a wide spread. What is worth understanding is which variables actually move your operational cost — as distinct from your facility bill.

Device count and vendor spread. A multi-vendor estate is harder and more expensive to maintain than a consolidated one, because spares, firmware knowledge and support relationships multiply. Third-party maintenance exists largely to collapse that spread back into a single contract.

How much of the estate is genuinely redundant. Real redundancy converts most component failures from incidents into scheduled work, which is dramatically cheaper. Partial redundancy — the common case — produces the worst economics, because you pay for the hardware without getting the response-time relief.

How well documented the environment is. Undocumented environments cost more to operate for the simple reason that every intervention starts with a discovery phase. This cost is invisible on any invoice and entirely real.

Change frequency. A cage that changes twice a year and a cage that changes twice a month are different operational products, whatever the rack count says.

For context on the facility side of the equation, our published guides on Hong Kong data centre locations and providers and what drives data centre costs in Hong Kong cover choosing a facility and understanding its pricing. This article is deliberately the question after those two: you already have the cage, so who operates it?

Frequently asked questions

What is the difference between colocation remote hands and a managed service?

Remote hands is a per-incident execution service: you describe a physical action, a technician on site performs it within an SLA. A managed service is a continuing operational relationship: monitoring, spare-parts logistics, documentation, change control and escalation, with physical intervention as one component. Remote hands answers "can someone press the button." A managed service answers "is anyone responsible for this rack."

Do we need both, or does one replace the other?

For most colocated firms, both. Remote hands is unbeatable on speed for simple actions because the technician is already in the building, and it should be pre-authorised for a defined list of safe tasks. A maintenance contract covers everything requiring parts, judgment, documentation or continuity. They are complements, and the useful work is writing down which category each foreseeable task falls into.

How do we know if our colocated infrastructure is actually being monitored?

Ask a specific question rather than a general one: if a redundant power supply in a specific server failed right now, who would know, how, and how soon? If the honest answer involves somebody happening to log in, the equipment is not monitored — it is observed occasionally. Loss-of-redundancy detection is the single most useful thing to verify, because those failures are silent by design.

We are an SFC-licensed firm. Does that change what we need from cage operations?

It changes the evidence requirements more than the technical ones. Asset accuracy, change records, authorisation trails and certified disposal evidence become things you must be able to produce, not just things that are good practice. The practical implication is that documentation and chain-of-custody should be contracted explicitly rather than assumed — including certified data-destruction certificates for any decommissioned equipment.

Is it worth moving out of colocation and into cloud instead?

Sometimes, and it is a genuinely open question rather than a foregone conclusion — but it is a different question from this one. Latency-sensitive execution infrastructure and cross-connects to market-data vendors are among the harder things to move, and a partial migration often leaves you operating a smaller cage with the same five unowned jobs. If you are considering it, decide the operating model for whatever remains in the cage either way.

How quickly can an engineer reach a Hong Kong data centre?

That depends on the facility, the time of day, and the access-control process — data centre access is deliberately not fast, and a first-time visitor without pre-registration can lose an hour at the security desk regardless of how quickly they crossed the harbour. This is why pre-registered, named engineers on a standing access list matter more than raw travel time, and why it should be arranged before the incident rather than during it.

What does Brocent actually do inside a data centre?

Rack and stack, decommission, hardware break-fix with parts, structured cabling, network device installation and commissioning, offsite staging and pre-configuration, UAT and commissioning reports, asset tagging, firmware and BIOS upgrades, and certified IT asset disposal. Brocent has had a Hong Kong office since 2016 and holds regional certified field-service engineers, with in-country spare parts in Hong Kong, mainland China, Japan and Singapore.

The point

Colocation is a clean, well-understood product with a clean, well-understood boundary — and the boundary is the problem. Everything on the facility's side of it is somebody's full-time job with an SLA attached. Everything on your side of it is somebody's job too, but in a small firm that somebody is often nobody in particular.

The fix is not exotic. Write down the five jobs. Decide, for each, whether it is handled by facility remote hands, by a maintenance contract, or by your own people. Pre-authorise the safe physical actions in advance. Produce a current rack elevation. Know where the spare is.

If your servers are in Tseung Kwan O, Kwai Chung, Chai Wan or anywhere else in Hong Kong, and you are not certain who goes to the cage on a Sunday night, talk to us — or if you would rather start with the paperwork, start with the rack elevation. It is the cheapest thing on the list and it usually tells you the most.