How Are Snapshot Storage Costs Billed?

Snapshot storage bills at $0.025 per snapshot-hour for every hour a snapshot exists, which makes it a wall-clock charge rather than a per-job one, so the monthly figure is the number of live snapshots multiplied by the hours they stay alive. Snapshots are deleted after 15 days per the snapshot runners documentation, which caps one forgotten snapshot at $9.00 (15 days times 24 hours times $0.025), and the daywise storage cost endpoint reports what actually accrued each day.

Answer

Two metered lines sit on top of runner minutes when a workflow uses snapshots, both from the pricing page, checked on 2026-08-13.

Restore is the line most teams budget for, because it moves with pipeline volume and appears per job. Storage is the line that surprises them, because it accrues on a repository that ran nothing all week. An alias created before a two week holiday bills $0.60 per day until the 15 day lifetime deletes it.

The rate carries no per-gigabyte term. A snapshot of a 40 GB disk and a snapshot of a 120 GB disk bill the same $0.025 for the same hour, so the two variables you control are how many snapshots you keep and how long each one lives. Disk size still matters for other reasons: capture time rises with the disk, which is why WarpBuilds/snapshot-save takes a wait-timeout-minutes input that defaults to 30, and a snapshot boot takes 45 to 60 seconds per the snapshot runners documentation.

That gives a small reference table you can read straight off the rate.

The middle column is the ceiling on anything nobody deletes, since the 15 day lifetime ends the meter on its own. The right column applies to an alias a workflow keeps refreshing, which never reaches expiry and therefore bills for the whole month.

Snapshot runners are supported only on WarpBuild Cloud Ubuntu runners, so this bill exists on part of the catalog, per the snapshot runners documentation. A snapshot label applied to a Windows, macOS, or BYOC runner is silently ignored, which also means it produces no storage charge.

Detail

The endpoint that reports storage by day

Snapshot restore shows up per job in the CI Billing report, where the summary cards break out total cost, runner cost, snapshot cost, and total jobs, and each table row carries a cost breakdown of runner plus snapshot, per the reports documentation. Storage does not attach to a job, so it needs its own read path.

It authenticates with a bearer API key created from the API keys page, the same key type the automation documentation uses for the runner and runner image endpoints.

curl -X GET 'https://api.warpbuild.com/api/v1/runner-images/daywise-snapshot-storage-costs?start_date=2026-07-01&end_date=2026-07-31' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer wkey-xxxx'

Both query parameters are required. The response is an array with one object per day, and each object carries three fields.

A two day window for an account that held one snapshot on the first day and two on the second reads like this, and the arithmetic is the flat rate applied to snapshot-hours: 24 hours at $0.025 is $0.60, and 48 snapshot-hours is $1.20.

[
  { "date": "2026-07-01", "amount": 0.6, "cumulative_amount": 0.6 },
  { "date": "2026-07-02", "amount": 1.2, "cumulative_amount": 1.8 }
]

The cumulative_amount field is what makes this useful for a budget check in a scheduled workflow: read the last element of the array for month-to-date without summing on the client. The endpoint is marked alpha in the API reference, so pin your tooling to a checked response shape and re-read the reference before relying on it in a billing alert.

A worked model: snapshot count against retention policy

Take a repository running 1,000 snapshot jobs a month and price three alias policies against each other. Restore fees are identical in all three at 1,000 jobs times $0.04, which is $40.00. Storage is what separates them.

The third row is the one worth staring at. Forty snapshots that nobody deletes each live out the full 15 days at $9.00, which adds $360.00 of storage for branches that were merged and forgotten. The first row costs $58.00 for the same 1,000 jobs.

Spread across jobs, the same numbers give a per-job figure to compare against the restore fee. One alias at $18.00 a month divided by 1,000 jobs adds $0.018 per job, below the $0.04 restore fee. The same alias serving 50 jobs a month adds $0.36 per job against a $0.04 restore fee, and that $0.36 usually erases the runner minutes the snapshot saved. Low traffic repositories are where alias sprawl hurts most.

Keeping aliases from accumulating

The pattern the snapshot runners documentation documents for feature branch work is one alias per project, refreshed by every run, rather than one alias per branch. Each push boots from the previous snapshot for that alias and writes a new one, so state compounds run over run while the live snapshot count stays flat.

jobs:
  build:
    runs-on: warp-ubuntu-latest-x64-4x;snapshot.key=my-project-snapshot
    steps:
      - uses: actions/checkout@v5

      - name: Install dependencies
        run: npm ci

      - name: Build
        run: npm run build

      - name: Cleanup credentials
        run: |
          rm -rf $HOME/.ssh $HOME/.aws
          git clean -ffdx

      - name: Save snapshot
        uses: WarpBuilds/snapshot-save@v1
        with:
          alias: "my-project-snapshot"
          fail-on-error: true
          wait-timeout-minutes: 60

The shape that grows your bill is an alias interpolated from the branch name, such as snapshot.key=deps-${{ github.head_ref }}. It mints a snapshot for every branch that ever runs the workflow and leaves each one to age out over 15 days, which is exactly the third row of the table above. Reach for per branch aliases only where branches genuinely need isolated disk state, and expect to pay $9.00 per branch for the privilege.

For anything that needs deleting before the lifetime expires, the API reference lists list, get, and delete operations under the snapshotter tag, including DELETE /snapshots/{id}, all marked alpha.

What the storage line never adds

Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee, so the storage line moves with snapshot-hours and nothing else. Signup includes $10 free credits, which covers roughly 400 snapshot-hours while you measure how many aliases your workflows actually keep alive. Every rate on this page comes from the pricing page and was checked on 2026-08-13.

Related Questions

Do I pay for snapshot storage on days when no job runs?

Yes. Storage bills $0.025 per snapshot-hour for every hour a snapshot exists, whether or not a job boots from it. One snapshot left alive costs $0.60 per day and $18.00 over a 30 day month, and the restore fee of $0.04 per job is the only part of the snapshot bill tied to job count. Both rates are listed on the WarpBuild pricing page, and How long do runner snapshots last? covers the lifetime that ends the meter.

Does a larger snapshot cost more to store?

The published rate is $0.025 per snapshot-hour and carries no per-gigabyte term, so a 40 GB snapshot and a 120 GB snapshot bill the same for the same hours. Disk size shows up in two other places. Capture takes longer, which is what the wait-timeout-minutes input on the save action controls, and a snapshot boot takes 45 to 60 seconds. The snapshot runners page lists the Ubuntu sizes that accept snapshot labels and their per-minute rates.

How do I see snapshot storage cost broken out by day?

Call GET /api/v1/runner-images/daywise-snapshot-storage-costs with the required start_date and end_date query parameters. The response is an array with one object per day carrying date, amount, and cumulative_amount, so month-to-date arrives without summing on the client. Retiring an alias early is covered in How do I invalidate a runner snapshot?.