The 38-Minute Outage That Became "Planned Maintenance"
You are the operations manager for a 4 MW colocation hall housing 62 tenants. Each caged suite carries a contractual guarantee of 99.982% monthly availability, with a 10% monthly recurring charge (MRC) credit for any breach. Last month a firmware upgrade on a downstream PDU, performed inside an approved Sunday change window, caused a 38-minute outage to a 12-rack suite. The change record has no back-out plan and no tenant notification. When the draft monthly service report was circulated, the event appeared as "planned maintenance" and the suite was reported at 100% availability, because the internal tooling labels any event occurring inside a change window as planned. Separately, hall PUE came in at 1.62 against a 1.45 target, and the BMS logged 14 repeat alarms from one chilled-water differential pressure sensor. Your finance director has asked why the report shows no credits, the tenant has requested the raw event log, and you must sign the report tomorrow.
1. The draft report codes the event as planned maintenance and shows 100% availability. Can that classification stand? Quantify the availability result and credit exposure, and state what you do before signing the report.
Read the worked answer
Test the classification against the contract, not the tooling. A planned event normally requires three things: advance written notice to the affected tenant, agreement to the window, and work that is genuinely maintenance rather than a failed change. None of the three is present. The build was internally approved, but the tenant received no notice and lost load unexpectedly. Internal change-window coding is an operational convenience and has no contractual standing. There is a second issue: the PDU served all 12 racks, so the suite was not concurrently maintainable at that moment, which may itself contradict the design commitment sold to the tenant.
Do the arithmetic. A 30-day month is 43,200 minutes. Availability = (43,200 − 38) / 43,200 = 99.912%. The contractual floor of 99.982% permits 43,200 × 0.00018 = 7.78 minutes. You exceeded the allowance by roughly 30 minutes, so this is a reportable breach.
Quantify credit. Apply the clause to the affected suite's MRC only, not the whole hall, and check whether the credit is per occurrence, whether a cap applies, and whether a repeat breach in the following month escalates the percentage.
Actions before signing. Reclassify the event as unplanned, correct the classification logic in the reporting tool so that change-window timing never determines planned/unplanned status, issue the tenant the event log with root cause and corrective actions inside the contractual notification window, and raise the misreporting itself as a reporting-integrity issue to compliance. Signing a knowingly wrong report converts a service credit into a fraud and certification exposure.
2. What process and problem-management actions follow, and how should PUE and the repeat BMS alarms be handled in the KPI pack?
Read the worked answer
Run it as a problem, not just an incident. The proximate cause is the firmware upgrade; the underlying causes are a change process that accepted a PDU build with no back-out plan, no tenant impact assessment and no pre-approved rollback window. Corrective actions should include: mandatory back-out plan and rollback test evidence for any change touching a live power path; impact classification that triggers tenant notification for changes inside a tenant's power chain; a post-implementation review record; and a review of whether that PDU firmware version is deployed elsewhere in the hall. Because the tenant will ask, confirm whether the same model and revision exist on the other 61 suites.
PUE. 1.62 against 1.45 is a 0.17 gap. Do not simply average it into an annual figure or restate the target retroactively. Decompose the gap: part-load inefficiency on UPS modules, CRAH fan energy at low load, over-cooling or simultaneous heating and cooling, and cooling set-point drift. Present PUE with load factor attached, because a low-load month can inflate PUE without any real degradation.
Alarm noise. Fourteen repeats from one differential pressure sensor is a sensor or filter maintenance issue and should be converted to a corrective work order, not reported as fourteen events. Track alarm floods as a separate KPI (alarms per operator per shift) and exclude that point from the operational alarm count only once the suppression is formally documented and time-bound.
Reporting discipline. Keep the raw event in the pack. A KPI set that is clean because it hides events destroys the credibility you need when a genuine Tier-level claim is made.