The 730-Hour Month

Ask your cloud provider's pricing calculator how many hours are in a month and it will say 730. Ask the same provider's service level agreement and it will say 30 days — 720 hours. Ask the billing system and it charged you 744 hours for an instance that ran all of October, 720 for November, and 672 for February. Three answers, one word, and no reconciliation anywhere in between.

Each individual gap is small enough to look like rounding: 1.9% between the calculator's month and a 31-day invoice, 7.9% between the calculator's month and February. That is exactly why it survives. A number that is wrong by two percent does not look like a modelling convention that nobody wrote down. It looks like noise, and noise gets averaged away in a spreadsheet that was never designed to notice it.

This briefing is about that spread — where each convention comes from, which one your invoice, your commitment and your uptime contract are each measured in, and how to stop three of them from living in the same model. It is the written companion to the vCPU to Compute Hours calculator, which converts a fleet into vCPU-hours against a stated month length so the convention is an input rather than an assumption.

Four Numbers, One Word

A month is not a unit of time. It is a name we give to twelve unequal intervals, and any engineering calculation that consumes one has to pick a length for it. There are five candidates, and they differ by more than ten percent:

The full spread from 672 to 744 is 10.7%. Two people estimating the same always-on instance with the same hourly rate can disagree by a tenth of the bill without either of them making a mistake — they simply chose different months. And this is not a hypothetical: the industry currently runs on two of these conventions at once, and they belong to different departments.

None of the four is a bug. Each is correct within its own frame, and each frame was chosen by someone who had a good reason and no obligation to tell the next person. The failure mode is not picking the wrong one. It is picking two.

Why 730 Is Not Arbitrary

The 730-hour month is not a marketing rounding. Multiply it back out and the reason appears immediately: 730 × 12 = 8,760, which is exactly 365 × 24. The convention is not a month at all — it is a year divided by twelve. Every calendar year contains 8,760 hours (8,784 in a leap year), so dividing by twelve produces a number whose only useful property is that it recomposes into the right annual total.

That single property explains both why the convention is everywhere and why every monthly projection built on it is wrong. Cloud providers state the definition plainly rather than hide it. AWS's pricing calculator FAQ puts it in one sentence — the calculator "assumes there are 730 hours in a month ((365 days × 24 hours) / 12 months in a year), which may be less or more than the actual hours in the current billing period" — and then walks through the divergence for a $0.10/hour On-Demand instance:

Read the last row against the first. Monthly, the estimate is off by as much as 7.9%. Annually, it is off by nothing at all. The 730-hour month is a lossless compression of the year into twelve identical boxes, and every individual box is the wrong size.

There is one more drift worth naming. Because 730 is built from a 365-day year, the convention silently discards the leap day. In a leap year the true annual total is 8,784 hours and the average month is 732. An organisation that models every month as 730 will under-forecast a leap year by 24 hours of always-on capacity per instance — the only case where the annual total does not cancel, and the one nobody adjusts for.

The Number on the Invoice

What you are actually billed is neither 730 nor 720. Since 2017, AWS has billed Linux instances per second with a 60-second minimum, and the other major providers meter sub-hourly as well. Metering granularity does not change the arithmetic of a full month though: an instance that is on for every second of a 31-day month is on for 744 hours, and that is what appears on the bill. Here is a non-leap year, month by month, for a single always-on instance priced at $0.10/hour:

Seven months bill 744 hours, four bill 720, one bills 672 — and only one of the twelve is within a rounding error of the 730-hour estimate. The practical consequence is a forecasting rule that most cost dashboards get backwards. A monthly projection built on 730 will show a "budget variance" of +1.9% every 31-day month and −7.9% every February, and an engineer will spend time investigating the long months and the short months as though traffic moved, when the only thing that moved was the Gregorian calendar.

Scale it and the false signal gets expensive to chase. A fleet with a $100,000 monthly compute bill running flat out will show +$1,920 in October and −$7,950 in February against a 730-hour forecast. None of that is a change in usage, and all of it lands in a variance report that someone has to explain. The fix is not to model better months. It is to forecast in hours per year and reconcile in days per month, so that the calendar is visible as a factor rather than baked into the baseline.

Commitments Are Measured in Hours

Reserved Instances and Savings Plans do not sell months. They sell hours of coverage, and the term is fixed in hours regardless of how the calendar falls: 8,760 for a one-year commitment, 26,280 for three years. That makes the month convention a first-order input to any commitment calculation, in a way that is easy to miss because the pricing pages quote discounts as percentages rather than hour counts.

The 720-hour path is the one to watch, and it is the one people reach for, because a "30-day month" feels like the conservative choice. It is not. Twelve 720-hour months is 8,640 hours, which leaves 120 hours a year of a continuously running instance outside the commitment — 1.4% of the term, billed at on-demand rates for every instance in the fleet. On a 100-instance fleet that is 12,000 uncovered instance-hours a year, and the discount you negotiated does not apply to a single one of them.

The mirror error is subtler and sits on the capacity-planning side. A commitment covers hours whether or not your workload runs in them: if you buy a 1-year RI and only use 4,800 hours, the remaining 3,960 hours are paid for and unused. That is why the breakeven question is really about utilisation — 8,760 hours of coverage against the hours your workload actually occupies — and why the same fleet can be over-committed in one quarter and under-committed in the next. Both readings need the hours, not the months, to be computed at all.

Your SLA Uses a Different Month

Here is where the two conventions stop being a curiosity and start being a contract. Cost models run on 730 hours. Reliability contracts run on 720. Google Cloud's reliability documentation states the basis in the column heading itself — "Estimated maximum downtime in a 30-day month" — and lists 99.9% as 43.2 minutes. That figure is not a coincidence: 720 hours × 0.1% = 0.72 hours = 43.2 minutes. A 730-hour month would give 43.8 minutes, and a 31-day month gives 44.64.

The 30-day convention is honest and it is the industry standard — budget arithmetic in the SRE literature has always assumed a 30-day window, which is why the burn-rate thresholds in the error-budget model are expressed against a 720-hour month. The trap is not the convention. The trap is comparing a vendor's "43.2 minutes per month" against your own measurement taken in a 31-day month, where the contract actually allows 44.64. Do that and your incident review will flag a breach that never happened, by 1.44 minutes. Run the comparison in February instead and the same 43.2-minute reference is 2.88 minutes stricter than the contract, so a genuine breach passes unnoticed.

The only figure that is comparable across the whole year is the annual one — 8.76 hours for three nines — and it is the figure almost nobody measures against, because dashboards are built monthly. If you want a monthly view that tracks the contract, compute the allowance from the month's own length. If you want a number that does not move, use the year.

Where the Mixing Bites

The failure mode is rarely a wrong convention. It is two right conventions in one calculation — the kind of thing that happens when a headline number and a formula are written on different days. A fleet-sizing sheet says "16 vCPUs × 730 hours = 11,680 vCPU-hours per month" on its summary tab, while the tab that turns hours into months divides by 720, because a different person built it and a 30-day month felt like the safer choice. Neither line is wrong on its own. They are 1.4% apart, and they describe different months.

That 1.4% does not stay small, because it is multiplied twice — once by the number of instances, and once by every downstream thing that consumes the figure:

Nine hundred and sixty dollars a year of pure ambiguity, from a fleet small enough to fit in one rack, decided by which line of which document someone copied. The same 1.4% applied to a commitment calculation leaves hours uncovered; applied to an SLA leaves minutes misattributed; applied to a capacity plan shifts the instance count. The number does not have to be large to matter — it has to be multiplied, and in infrastructure arithmetic everything is multiplied.

The remedy is a three-line note that goes at the top of the model rather than in a footnote, so that the next person to open the spreadsheet inherits the convention instead of guessing it:

Two rules make the note enforceable. First, never let a monthly figure and an annual figure into the same comparison — convert one of them. Second, when a number derived from hours turns up somewhere new, carry the month length with it; "11,680 vCPU-hours on a 730-hour month" survives a change of convention, and "11,680 vCPU-hours" does not.

The calculators that this briefing pairs with all take the month length as an argument rather than assume it, so the arithmetic stays honest whichever convention a team has standardised on. The vCPU to Compute Hours calculator converts a fleet profile into vCPU-hours, vCPU-days and vCPU-months against the length you supply; the RI vs Spot Breakeven calculator prices a commitment against the hours a workload actually occupies; the Error Budget calculator applies the 30-day window that the SLO literature uses; and the Cron Execution Frequency matrix shows how many times a schedule fires in a standard month, which is the same convention question asked by a scheduler instead of a billing system.

Frequently Asked Questions

How many hours are in a month for cloud billing?

The billing convention is 730 hours, defined as (365 days × 24 hours) ÷ 12 months. AWS states this explicitly in its pricing calculator FAQ. No actual month is 730 hours long: a 28-day February is 672, a 30-day month is 720 and a 31-day month is 744. The 730 figure is an annual average, which is why it is exactly right over a year and wrong in every individual month.

Does AWS actually charge 730 hours per month?

No. AWS bills per second with a 60-second minimum on Linux, so an always-on instance in a 31-day month is charged 744 hours and one in February is charged 672. The 730-hour figure is a modelling convention used by the pricing calculator, not a billing rule. AWS's own FAQ notes that its monthly estimate "may be less or more than the actual hours in the current billing period."

Why does 99.9% uptime equal 43.2 minutes per month?

Because SLA tables use a 30-day month of 720 hours, not the 730-hour billing month. 720 hours × 0.1% = 0.72 hours = 43.2 minutes, which is the figure Google Cloud publishes for a 30-day month. The same 99.9% allows 44.64 minutes in a 31-day month and 40.32 minutes in a 28-day February. Across a whole year the allowance is 8.76 hours.

How many hours are in a year for reserved instance commitments?

8,760 hours (365 days × 24 hours), and 26,280 hours for a 3-year term. Reserved Instances and Savings Plans are commitments measured in hours of coverage, not in months, so a one-year commitment covers 8,760 hours of a given instance regardless of how the calendar falls. Modelling the year as twelve 720-hour months gives 8,640 hours and leaves 120 hours a year uncovered at on-demand rates.

Methodology & Disclosure

Hour counts are exact arithmetic on the Gregorian calendar: a day is 24 hours, a non-leap year is 365 days (8,760 hours), a leap year is 366 days (8,784 hours), and the 730-hour monthly convention is (365 × 24) ÷ 12 as defined by AWS's pricing calculator documentation. The month-by-month billed-hour table is a non-leap year (2026) for a single continuously running instance, and assumes second-level metering with a 60-second minimum, which rounds to a whole hour only in this table and never on an invoice. Uptime allowances are computed as (1 − availability) × window length, using a 30-day month of 720 hours for the convention column because that is the basis the published SLA tables state, and the month's own length for the other columns. Hourly prices in worked examples are illustrative and stated in USD; they are used only to make a percentage legible and are not vendors' current list rates — verify rates at the source before budgeting. Reserved Instance and Savings Plan terms are taken as 8,760 hours for one year and 26,280 hours for three. This site takes no sponsorship, no affiliate commission and no vendor payment of any kind; the vendors named here have no relationship with jslet and did not review this briefing.

References & Further Reading

1. AWS Pricing Calculator, Frequently Asked Questions — the 730-hour month definition, "may be less or more than the actual hours in the current billing period", and the month-by-month variance worked example. calculator.aws
2. AWS Pricing Calculator, Pricing Assumptions — monthly normalisation to 730 hours, 4.34 weeks per month and 4.3 occurrences of a weekday per month. calculator.aws
3. Google Cloud Architecture Center, Building blocks of reliability — uptime SLA tables with "estimated maximum downtime in a 30-day month", including 99.9% as 43.2 minutes. cloud.google.com/architecture
4. Beyer et al. Site Reliability Engineering and The Site Reliability Workbook — error budgets and burn-rate thresholds defined over a 30-day window. sre.google
5. Amazon EC2 documentation — per-second billing with a 60-second minimum for Linux instances, and Reserved Instance term lengths expressed in hours. docs.aws.amazon.com
6. Related: vCPU to Compute Hours Calculator · The Reservation Trap: 3-Year RI vs AWS Spot · The Error Budget: 99.9% = 43.2 Minutes/Month · Cron Execution Frequency Matrix · Kubernetes Pod Cost Calculator

📜 Copyright & Attribution