Milliseconds to Minutes

Your Monitoring Says 1 380 000, the Postmortem Says 23 Minutes

Incident tooling measures in milliseconds because that is what timestamps subtract to. Everything downstream of the incident does not: the status page, the customer email, the service credit clause and the error budget are all written in minutes. So the first line of every postmortem template — duration — starts life as a seven-figure integer copied out of an alerting API, and somebody has to turn it into a number a review meeting can discuss.

Conversion factor: 1 ms = 1/60 000 min, so divide milliseconds by 60 000. An outage exported as 1 380 000 ms is 23 minutes, which on a 99.9 % objective consumes just over half of the 43.2 minutes that month allows.

Why the Two Units Never Meet in the Middle

Exporters emit raw durations

An alert that opened and closed leaves two timestamps; the difference lands in a field with no unit attached and, by convention across most incident APIs, it is milliseconds.

Contracts count in minutes

Service agreements state monthly uptime percentages and credit tiers, and the arithmetic behind them is always expressed as allowed minutes of unavailability.

An error budget is a quantity to spend

The gap between your objective and 100 % is a real allowance. Framing it in minutes turns an abstract percentage into something a team can weigh against a risky deploy.

Detection is spent before anyone acts

Time to detect, time to page and time to mitigate all come out of the same allowance, and at tight objectives the detection portion alone can finish the month.

Getting an Exported Duration Onto the Incident Timeline

The workflow starts with a number pasted out of a dashboard and finishes with a sentence in a document somebody outside engineering will read.

Paste the duration exactly as exported

Drop 1 380 000 or 259 200 straight into the left field. Spaces used as thousands separators are ignored and a comma is accepted for the decimal point, so a value copied out of a table needs no cleaning up.

Compare it with the month's allowance

Set the result against the table below. Twenty-three minutes is comfortable at 99.5 %, more than half the month's budget at 99.9 %, and several months' worth at 99.99 %.

Reverse it when you are setting a threshold

Press the swap button (↔) for min → ms, the direction you need when an alerting rule wants a duration in milliseconds and the on-call policy is written as "page after 5 minutes".

Copy the clean figure into the writeup

The copy control hands over the number with no unit and no spacing, ready for a spreadsheet cell where the incident register totals a quarter's minutes. Ctrl + C inside the field behaves the same way.

Note on the window: the figures here use a rolling 30-day month of 43 200 minutes, which is the usual SLO convention. The converter's own month unit is the 30.436875-day average instead, so pick minutes rather than months when the budget window matters.

Availability Targets and the Downtime They Buy

Each objective against the unavailability it permits across a 30-day window of 2 592 000 000 ms, shown as the raw export figure, the minutes a report would quote, and how long that actually feels.

Availability target	Budget (ms)	Budget (minutes)	Reads as
99 %	25 920 000	432	7 h 12 min
99.5 %	12 960 000	216	3 h 36 min
99.9 % — three nines	2 592 000	43.2	43 min 12 s
99.95 %	1 296 000	21.6	21 min 36 s
99.99 % — four nines	259 200	4.32	4 min 19 s
99.999 % — five nines	25 920	0.432	25.9 s

Each extra nine divides the allowance by ten. That is the whole reason these targets are argued over so hard: moving from 99.9 % to 99.99 % does not mean being slightly more careful, it means fitting an entire month of failures, deploys and detection lag into four and a third minutes.

What This Pair Does During an Incident Review

Paste from the dashboard, read the answer

The left field takes the exported integer as it comes and the minutes appear while you type, so an incident channel gets a human duration without anyone opening a calculator.

Go the other way for an alert rule

Swapping the pair turns a policy stated in minutes into the millisecond threshold a monitoring rule or a probe configuration expects.

Hours and days for the bad ones

Both dropdowns are searchable across every time unit, so a multi-hour incident can be read straight in hours rather than as a four-figure minute count.

Seven-figure exports stay readable

Thousands are spaced apart in the result and very large values switch to scientific notation, so a quarter of accumulated downtime does not turn into a wall of digits.

Questions Raised in the Postmortem Review

How much downtime does each availability target allow in a month?

Take the 43 200 minutes in a 30-day window and multiply by the share you are allowed to lose. At 99.9 % that is 0.1 %, or 43.2 minutes; at 99.95 % it halves to 21.6; at 99.99 % it drops to 4.32; and at 99.999 % you are left with 0.432 minutes, under twenty-six seconds. Quote the minutes, not the percentage, when you want a room to understand what an extra nine costs.

An incident exporter logged 1,800,000 — what goes in the report?

Thirty minutes. Written that way it is immediately comparable with everything else in the document: it is 69.4 % of a 99.9 % monthly budget, it exceeds a 99.95 % budget outright, and it is nearly seven months of allowance at 99.99 %. Keep the raw millisecond figure in an appendix if the timeline needs precise ordering, but the summary line should carry the minutes.

Does a partial outage burn the whole error budget?

It depends which kind of indicator you defined. A request-based one counts failed requests against total requests, so half an hour at a 20 % error rate costs roughly the equivalent of 6 minutes of full unavailability, not 30. A window-based one marks each minute good or bad against a threshold, and every minute that breaches it is spent in full whether 20 % or 100 % of traffic was affected. Decide which you are using before the incident, because arguing about it afterwards never ends well.

What does a 14.4x burn rate alert mean?

Burn rate is the observed failure rate divided by the rate the objective tolerates, so 1x exactly exhausts the allowance by the end of the window and 14.4x spends it fourteen times faster. That specific figure comes from the Google SRE alerting recipe: sustained over one hour it consumes 2 % of a 30-day budget, because one hour is 1/720 of the window and 14.4/720 is exactly 2 %. At three nines it means burning about 51.8 seconds of the 43.2-minute allowance in a single hour — enough to page someone immediately, while a 6x rate over six hours gets a slower ticket.

What does a five-minute detection delay cost at 99.99 %?

The entire month, with change. Five minutes is 300 000 ms and the four-nines allowance is 259 200 ms — so a single hard outage would blow through the budget before the first responder had even acknowledged the page, let alone mitigated anything. This is why tight objectives force investment in detection rather than in heroics: at that level the only affordable incidents are the ones an automated rollback closes without a human in the loop.