SLA Earnings Backtester

The SLA (Service Level Agreement) earnings backtester lets you answer a practical question before you list: if clients had rented with reliability target r and I offered SLA at confidence p, how would that have affected my earnings on this machine over the last few months? Console hosts: use Set Pricing → SLA in the web console to preview SLA charges — you do not need this API. API hosts: this endpoint replays historical earnings through SLA math to estimate SLA charges and worst-day credit risk before listing. (r = reliability level used as both claim and target in the simulation; p = host confidence — both defined in Query parameters below.) It replays your machine’s real historical compute earnings and reliability through the same SLA settlement math used in production, then compares the simulated result to what you actually earned from SLA (if anything). See Choose your path below.

Don’t want to use the API? The backtester is optional. Use the web console SLA preview and the economics walkthrough on SLA Offers to evaluate SLA before listing. The backtester is for hosts who want historical replay via the API.

Choose your path

If you want to…	Use
Preview SLA before your first listing	Web console (Set Pricing → SLA on the machine page) — no API key needed
Simulate historical earnings for one machine	This page’s single-machine `curl` example
Review many machines at once	Fleet workflow below (advanced; Linux/macOS + `jq`)

When to use it

Use the backtester before you enable SLA on a listing, or when you want to tune parameters. The machine needs at least a few weeks of rental history. If has_data is false, widen the date range or pick a machine with more rental activity. Use the backtester to:

Pick a reliability claim and confidence before you enable SLA on a listing
Compare how SLA charge and worst-case credit change across targets
Stress-test a lower reliability assumption before you commit
Compare to history — each day includes historical_sla, your machine’s realized SLA earnings on that day (zero if you were not offering SLA)

For how SLA offers work once listed, see SLA Offers.

How it works

You choose a machine, date range, reliability level (r), and confidence (p).
The API loads per-day earnings from your machine’s rental history.
For each active day, it computes GPU, storage, and bandwidth earnings plus simulated SLA host earnings.
It returns a day-by-day breakdown and summary totals.

Simulated vs listing parameters. In the backtester, reliability claim and client target are both set to r. That is a conservative what-if: it pretends every client targeted your claim. When you list, you set only sla_r_claim (and sla_sigma_x); clients choose their own target_reliability at search/rent time. Workflow: backtest worst_day_loss at a candidate claim level, then verify visible SLA charges in Set Pricing → SLA (or dph_total in search at realistic client targets) before listing. Active vs idle days. Idle days are days with no rental earnings on the machine (no active compute rental). These days typically produce no SLA charge or credit in the simulation. Days with no rental activity appear in the results as zero-filled rows but do not count toward covered_days. Only days with actual earnings are replayed through SLA math.

Simulation vs live listing

The backtester sets claim equal to target and may show higher SLA charges than live listing when clients choose targets below your claim.
For client-visible pricing (dph_total), use Set Pricing → SLA in the console or search with a realistic target_reliability.
For tail risk, trust worst_day_loss, not headline total_sla.
Timescale mix (β) is derived from r (weights recent vs longer-term uptime in settlement). Hosts cannot set β via the listing API.

Before you start

Prerequisites: API key with machine_read permission, machine ID from the Host Machines page, and curl (or Postman). On Windows, use WSL or Postman. This is the same numeric machine ID as machid on the earnings API and machine in listing requests.

Open Account → API Keys in the console and create a key with machine_read enabled.
Copy the token and use Authorization: Bearer YOUR_API_KEY in the examples below. See Create API Key and Authentication.
Find your machine ID on the Host Machines page. The machine must have at least a few weeks of rental activity — new or idle machines should use the console Set Pricing → SLA preview instead (the backtester returns has_data: false without sufficient history).
Run the baseline request in Example request and check has_data in the response.

API reference

The backtester is available through the REST API only. You must own the machine and use an API key with machine_read permission. Python SDK (vastai package) support is not yet available — use the curl examples below.

GET /api/v0/host/sla_backtest/

Requires Bearer authentication. This endpoint is rate-limited like other host API endpoints — see Rate Limits and Errors for retry guidance.

Query parameters

Parameter	Required	Description
`machine_id`	Yes	ID of your machine
`r`	Yes	Reliability level to simulate (greater than 0 and at most 0.9999). Used as both claim and client target in the simulation. Example: `0.95` = 95%. Exactly `1.0` is rejected.
`p`	No	Host confidence (greater than 0 and less than 1 — not equal to 1). Maps to the same spread used when listing with `sla_sigma_x` — see Confidence values below. Default: `0.6667` (normal confidence, ≈ 67%).
`start_date`	No	Range start as Unix epoch seconds. Default: 90 days before `end_date`.
`end_date`	No	Range end as Unix epoch seconds. Default: now.
`reliability`	No	Optional flat uptime override (greater than 0 and at most 1). Ignores historical uptime — useful for what-if analysis. Use `0.01` to approximate near-total downtime; `0` is rejected with `400 bad_request`.
`beta`	No	Not user-configurable — the API derives timescale weighting from `r`.

Limits

Limit	Value
Default lookback	90 days
Maximum range	366 days (inclusive)
Ownership	Must own the machine
Rate limits	Per-endpoint; see Rate Limits and Errors

Example request

Minimal baseline (default 90-day lookback — no custom dates required):

curl -s -H "Authorization: Bearer YOUR_API_KEY" \
  "https://console.vast.ai/api/v0/host/sla_backtest/?machine_id=12345&r=0.95&p=0.6667"

Custom date range (optional — Jan–Apr 2024 for illustration):

# start_date = Jan 1, 2024 UTC; end_date = Apr 1, 2024 UTC
# Linux: date -u -d '2024-01-01' +%s
# macOS: date -u -j -f '%Y-%m-%d' '2024-01-01' +%s
# On Windows, use WSL or an online epoch converter.
curl -s -H "Authorization: Bearer YOUR_API_KEY" \
  "https://console.vast.ai/api/v0/host/sla_backtest/?machine_id=12345&r=0.95&p=0.6667&start_date=1704067200&end_date=1711929600"

Compare two confidence levels on the same history:

# Normal confidence (~67%, default 0.6667)
curl -s -H "Authorization: Bearer YOUR_API_KEY" \
  "https://console.vast.ai/api/v0/host/sla_backtest/?machine_id=12345&r=0.99&p=0.6667"

# High confidence (~83%) — tighter spread, lower simulated SLA charges
curl -s -H "Authorization: Bearer YOUR_API_KEY" \
  "https://console.vast.ai/api/v0/host/sla_backtest/?machine_id=12345&r=0.99&p=0.83"

Stress-test with flat 90% uptime:

curl -s -H "Authorization: Bearer YOUR_API_KEY" \
  "https://console.vast.ai/api/v0/host/sla_backtest/?machine_id=12345&r=0.99&p=0.6667&reliability=0.90"

Reading the response

If you only read three fields: Check has_data (widen dates if false), then summary.worst_day_loss, then summary.total_sla. A successful response looks like this (fields abbreviated):

{
  "success": true,
  "machine_id": 12345,
  "has_data": true,
  "start_day": 19723,
  "end_day": 19812,
  "covered_days": 45,
  "skipped_days": 45,
  "reliability": 0.998500,
  "fleet_reliability": 0.991200,
  "params": {
    "r": 0.95,
    "p": 0.6667,
    "sigma_x": 0.5,
    "reliability": null,
    "beta": 0.5
  },
  "daily_results": [
    {
      "day": 19723,
      "gpu": 84.0,
      "storage": 2.4,
      "bandwidth": 0.1,
      "uptime": 1.0,
      "sla": 0.18,
      "historical_sla": 0.0
    }
  ],
  "summary": {
    "total_gpu": 3780.0,
    "total_storage": 108.0,
    "total_bandwidth": 4.5,
    "total_sla": 8.1,
    "total_earnings": 3900.6,
    "total_historical_sla": 0.0,
    "worst_day_loss": 42.0,
    "reserve": 0.0
  }
}

Top-level fields

Field	Meaning
`has_data`	`true` if at least one day in the range had earnings to replay. When `false`, there was no billable rental activity in the range: `covered_days` is `0`, `skipped_days` equals the number of days in the requested window, `daily_results` contains one zero-filled row per day in the window (not an empty array), summary totals are `0.0`, and top-level `reliability` is `null`. Try a wider window or a machine with more rental history.
`start_day`, `end_day`	UTC day indices. The API computes `day = floor(epoch_seconds / 86400)`. Same encoding as `daily_results[].day`. To convert a day index to an approximate UTC date: `date -u -d "@$((day * 86400))" +%Y-%m-%d` (Linux). Do not assume `day × 86400` equals UTC midnight for that calendar day. Most hosts can ignore these and use `start_date`/`end_date` in requests.
`covered_days`	Days with rental activity replayed through SLA math
`skipped_days`	Days in the range with no activity (zero-filled in `daily_results`)
`reliability`	Actual uptime ratio over the range (`total uptime / total active time`)
`fleet_reliability`	Average reliability across your machines (including this one). Context only; may be uninformative if you operate a single machine.

Per-day fields (`daily_results`)

Field	Meaning
`gpu`, `storage`, `bandwidth`	That day’s compute earnings breakdown ($)
`uptime`	Uptime fraction for the day (0–1), or your flat override if set
`sla`	Simulated SLA host earnings for the day. Positive = you keep the SLA charge; negative = you credit the client
`historical_sla`	What you actually earned from SLA that day (signed). Zero if you were not offering SLA

Review sla day by day in daily_results to see which days would have helped or hurt under the chosen parameters. Compare against historical_sla to see how simulated economics differ from reality.

Summary fields

Field	Meaning
`total_gpu`, `total_storage`, `total_bandwidth`	Compute earnings over covered days
`total_sla`	Net simulated SLA earnings. Positive = SLA would have added income overall
`total_earnings`	Compute + simulated SLA
`total_historical_sla`	Sum of realized historical SLA in the range
`worst_day_loss`	Largest single-day client credit (your worst simulated loss). Always a non-negative dollar amount — unlike signed `sla` / `sla_earn` fields
`reserve`	Reserved for future use — ignore in production decisions today.

Interpreting results

Mostly positive `sla` values

Your historical reliability was strong relative to the simulated target. SLA would likely have been a net positive — small SLA charges on strong days, few days with credits.

Negative `sla` on specific days

Those days had reliability below the simulated target. The magnitude shows how much you would have credited. If you see clusters of negative days, consider a lower claim, wider confidence, or fixing reliability before listing SLA.

`total_sla` near zero

Break-even territory — SLA charges and credits roughly balance. Typical when your actual reliability matches the simulated target.

`total_sla` strongly negative

Under the simulated parameters, SLA would have cost you money over this window. Either improve reliability, lower the claim, or widen confidence before listing.

Using `reliability` override

Setting reliability=0.90 while keeping r=0.99 answers: if every active day had 90% uptime, how bad would SLA credits get? Use this to understand worst-case credit exposure before committing to a high claim.

Confidence values (`p`)

p and sla_sigma_x use different scales — do not copy numeric values between them. For example, p=0.5 (wide confidence) maps to sla_sigma_x ≈ 1.0, not 0.5. Use the table below to translate between the two.

The backtester accepts p (confidence) instead of sla_sigma_x. The mappings below match common listing values:

Confidence `p`	Approx. label	Listing equivalent
`0.83`	Tight	`sla_sigma_x ≈ 0.2`
`0.6667`	Normal (default)	`sla_sigma_x ≈ 0.5`
`0.50`	Wide	`sla_sigma_x ≈ 1.0`

Tighter confidence (higher p) does not reduce credit owed on a miss — use worst_day_loss and reliability= overrides to model settlement exposure.

Error responses

HTTP	`error` / shape	Cause
400	`invalid_range`	Date window invalid
400	`range_too_large`	Window exceeds the maximum span
400	`bad_request`	Out-of-range `r`, `p`, or date parameters
400	`invalid_params`	Simulation math failure after validation (check claim/confidence inputs)
403	`not_owner`	Machine belongs to another host
404	`machine_not_found`	Invalid `machine_id`
429	(rate limited)	Too many requests — retry with backoff. See Rate Limits and Errors.

For missing or invalid API keys and permission denials (machine_read), see Authentication.

Recommended workflow

Run a baseline backtest on a machine with at least a few weeks of rental history:
- Check your machine’s uptime history on the Host Machines page, then use the console SLA preview or backtester — do not rely on the dashboard reliability score alone (see Machine reliability score vs SLA reliability).
- Choose an r at or slightly below the claim you plan to publish.
- Use normal confidence (p=0.6667).
- If has_data is false, widen the date range or wait for more rental history.
Check worst_day_loss — can you absorb that credit from a bad day?
Try a higher r (for example 0.99) and see how total_sla changes.
Run a stress test with reliability=0.90 at your intended claim.
List with sla_r_claim — set claim (and sla_sigma_x) on the offer; clients choose their own targets in search (see SLA Offers).

Fleet workflow

This section is for hosts automating fleet review. Console-only hosts can run the baseline curl once per machine instead.

export VAST_API_KEY="YOUR_API_KEY"

List machine IDs: vastai show machines -q (numeric IDs only) or vastai show machines --raw | jq -r '.machines[].id'.
Run backtests sequentially (one machine at a time):

for id in $(vastai show machines -q); do
  resp=$(curl -s -H "Authorization: Bearer $VAST_API_KEY" \
    "https://console.vast.ai/api/v0/host/sla_backtest/?machine_id=$id&r=0.95&p=0.6667" \
    || echo '{"error":"request_failed"}')
  if echo "$resp" | jq -e '.error' >/dev/null 2>&1; then
    echo "machine_id=$id error: $(echo "$resp" | jq -r '.error')"
  else
    echo "$resp" | jq '{machine_id: '"$id"', worst_day_loss: .summary.worst_day_loss, total_sla: .summary.total_sla, has_data: .has_data}'
  fi
  sleep 2
done

Expect roughly two seconds per machine minimum (sleep 2 plus request time). For 50 machines, budget at least a few minutes. Run off-peak before a fleet SLA rollout. On 429, back off per Rate Limits and Errors. Parallel requests are not recommended unless you implement backoff.

Compare worst_day_loss and total_sla across machines.
Apply sla_r_claim / sla_sigma_x when listing via the API (see SLA Offers).

When stuck

has_data: false — Widen the date range or wait for rental history.
401 — Check API key permissions (machine_read) and Bearer header format.
Still stuck — Ask in the host Discord.

SLA Backtest API — formal API reference for this endpoint
SLA Offers — listing parameters, economics, and risk scenarios
SLA Coverage (clients) — how renters choose targets and read dph_total
API permissions — machine_read scope required

Concepts

Guides

CLI

SDK

Choose your path

When to use it

How it works

Before you start

API reference

Query parameters

Limits

Example request

Reading the response

Top-level fields

Per-day fields (`daily_results`)

Summary fields

Interpreting results

Mostly positive `sla` values

Negative `sla` on specific days

`total_sla` near zero

`total_sla` strongly negative

Using `reliability` override

Confidence values (`p`)

Error responses

Recommended workflow

Fleet workflow

When stuck

​Choose your path

​When to use it

​How it works

​Before you start

​API reference

​Query parameters

​Limits

​Example request

​Reading the response

​Top-level fields

​Per-day fields (daily_results)

​Summary fields

​Interpreting results

​Mostly positive sla values

​Negative sla on specific days

​total_sla near zero

​total_sla strongly negative

​Using reliability override

​Confidence values (p)

​Error responses

​Recommended workflow

​Fleet workflow

​When stuck

​Related documentation

Choose your path

When to use it

How it works

Before you start

API reference

Query parameters

Limits

Example request

Reading the response

Top-level fields

Per-day fields (`daily_results`)

Summary fields

Interpreting results

Mostly positive `sla` values

Negative `sla` on specific days

`total_sla` near zero

`total_sla` strongly negative

Using `reliability` override

Confidence values (`p`)

Error responses

Recommended workflow

Fleet workflow

When stuck

Related documentation