Spot Instance Utilization Rate Estimator

The Spot Instance Utilization Rate Estimator measures the share of provisioned spot capacity that produced useful workload time. It compares productive compute hours with total provisioned spot hours and separately reports interruption or retry hours so teams can distinguish low utilization from disruption overhead. The metric is useful for batch platforms and cost reviews where a low spot price can be offset by idle capacity, queue delays, repeated work, or inefficient scheduling.

Use the result as an operational efficiency signal, not as a direct measure of savings. A spot fleet can have high utilization and still be expensive if the rate is high, or low utilization and still be acceptable when capacity is intentionally held for a strict deadline. Keep the measurement window and instance-equivalent units consistent, and use billing or scheduler telemetry to avoid mixing requested capacity with actual provisioned time.

Inputs

hr
hr
hr
Result
Spot productive utilization
Idle / nonproductive hours
Retry share of provisioned hours
Productive hours
Provisioned hours

1. Enter provisioned spot hours
Use actual billed or provisioned instance-equivalent hours for the measurement period.

2. Enter productive hours
Count time that directly advanced successful workload execution.

3. Enter retry and recovery hours
Track recomputation, restart, or recovery time caused by interruptions separately when available.

4. Use one normalization basis
If multiple instance sizes are included, normalize them before combining hours so capacity units are comparable.

5. Review idle and retry shares
Low productive utilization can come from ordinary idle time, interruption overhead, or both.

6. Investigate the cause before changing capacity
Use scheduler, checkpoint, and queue data to determine whether the issue is sizing, orchestration, or spot stability.

Productive utilization = Productive workload hours ÷ Provisioned spot hours × 100Retry share = Retry hours ÷ Provisioned spot hours × 100Idle/nonproductive hours = max(Provisioned hours − Productive hours − Retry hours, 0)

Where:

  • Provisioned spot hours — total spot capacity made available during the period
  • Productive workload hours — capacity time that advanced successful output
  • Retry hours — capacity time spent repeating or recovering interrupted work

Assumptions: Productive and retry hours are mutually exclusive and are measured using the same equivalent capacity unit as provisioned hours.

What the result means

The main result shows what percentage of provisioned spot capacity directly produced useful workload progress.

If productive plus retry hours exceed provisioned hours, recheck the measurement definitions or normalization basis.

Given

  • 5,000 provisioned spot hours
  • 3,950 productive hours
  • 350 retry hours

Calculation
Productive utilization = 3,950 ÷ 5,000 × 100 = 79.00%
Retry share = 350 ÷ 5,000 × 100 = 7.00%
Idle/nonproductive hours = 5,000 − 3,950 − 350 = 700 hours

Result
79.00% productive utilization

The fleet spent 79% of provisioned capacity on productive work, 7% on retry activity, and the remaining 14% idle or otherwise nonproductive.

Should retry hours count as productive utilization?

Usually no when the goal is to measure useful completed progress. Keeping retry time separate makes interruption overhead visible.

What if I only know productive and provisioned hours?

Enter zero for retry hours. The utilization result still works, but the nonproductive remainder will combine idle time and unmeasured recovery overhead.

Can I combine different instance types?

Yes only after converting them to a consistent normalized capacity unit. Raw hours from very different instance sizes are not directly comparable.

Does low utilization mean spot is the wrong pricing model?

Not by itself. Low utilization can reflect workload scheduling, overprovisioning, or intentional headroom. Compare cost per completed unit and deadline performance as well.

How often should I calculate this metric?

Use a cadence that matches workload variability and billing review. Weekly or monthly views can both be useful, provided the definitions stay consistent over time.