---
title: "We do not delete your backups when your card fails"
description: "The moment a customer most needs their data is often the moment their billing broke. So a failed payment starts a ladder, not a deletion, and downloads keep working the whole way down."
url: "https://saved.sh/blog/we-do-not-delete-when-your-card-fails"
date: "2026-08-01"
author: "saved.sh"
tag: "Pricing"
---

A company gets breached on a Tuesday. In the scramble, nobody notices that the
card on file expired last month, or that the finance contact who receives the
invoices left in June.

By the time someone thinks to restore from backup, the account is delinquent.

This is not a hypothetical edge case. Billing failures cluster around exactly the
kind of organisational disruption that also causes data loss, which means a
backup product's dunning policy is a data-loss policy whether it was designed as
one or not.

## What we do [#what-we-do]

<Figure caption="The ladder stops the service. It never stops your access to what you already stored.">
  <BillingLadder />
</Figure>

Credit runs out and we warn you. At day seven new work stops: no new runs,
schedules paused, and configuration stays editable so you can fix the setup while
you fix the billing. At day thirty it goes read-only.

Downloads work at every rung. Nothing is deleted for a year.

<Aside title="The one number that matters">
  A year. Not thirty days, not ninety. Long enough that a lapsed card, an unread
  email, a departure, or a company going quietly through a bad quarter does not
  turn into permanent data loss.
</Aside>

## Why "stopped" and "blocked" are different rungs [#why-stopped-and-blocked-are-different-rungs]

There is a distinction in the middle of that ladder worth explaining, because it
came out of asking what a delinquent customer is actually trying to do.

At **stopped**, new runs are paused but configuration is still editable. That is
deliberate. Someone whose billing has lapsed is frequently also mid-way through
fixing whatever caused the disruption, and locking their configuration at that
moment punishes the recovery, not the debt.

At **blocked**, nothing new is created or modified. Even here, every artifact
that already exists is readable and downloadable.

<Stats>
  <Stat value="7" unit="days" label="Before new work stops" />

  <Stat value="30" unit="days" label="Before read-only" />

  <Stat value="365" unit="days" label="Before anything is deleted" />
</Stats>

## No late fees [#no-late-fees]

No penalties, no interest, no reactivation charge. A late fee on an unpaid backup
bill collects almost nothing and converts a lapsed customer into an angry one.
Paying the invoice reverses the ladder from any stage.

## The incentive problem, named [#the-incentive-problem-named]

It is worth being direct about why this is not obvious. A backup vendor holding
delinquent customers' data has enormous leverage, and the shortest path to
collecting an unpaid invoice is to make the data hard to reach.

We think that is a genuinely bad thing to build, and the fact that it works is
what makes it worth refusing on purpose rather than by omission.

<Aside title="What to check with any vendor, including us" tone="accent">
  Find the deletion timeline in their terms. Not the dunning schedule, the deletion
  timeline. If it is thirty days, or absent, you have learned what happens to your
  data on your worst month.
</Aside>

## Getting your data out is separate from paying for it [#getting-your-data-out-is-separate-from-paying-for-it]

Availability is unconditional; the bytes are metered. Those two things are not in
tension, and keeping them separate is what stops a billing state from becoming a
custody question.

Your backups are yours. The invoice is a different conversation.