Backup Statuses

Rewind reports backup state on two surfaces, and they use two different vocabularies. Reading the wrong one is the most common source of confusion, so start by matching the surface to the question you're asking:

Question	Endpoint	Field
Is this account healthy right now?	List accounts / Get account	backup_status
How did a specific backup job turn out?	List backups	status

The two can look like they disagree for the same account — that's expected, and the sections below explain why.

Per-job status — List backups

Each job in List backups carries a status with one of four values:

Value	Meaning
success	The backup completed — including a backup that skipped some items but failed none.
failure	The backup failed, partially completed, or was invalidated.
in_progress	The backup is still running. Not an outcome yet.
unknown	An unrecognized backup state. Rare.

A success can include skipped items

A backup that failed nothing but skipped some items is a success, not a failure. The skipped items are still counted in items_skipped_count, so a success can legitimately carry a non-zero skip count. Many Jira, Confluence and GitHub accounts skip a portion of items on every run — that's normal, and it is not a partial failure.

Reading a failure

A failure does not necessarily mean data was lost. Use the item counts to interpret it:

Field	How to read it
items_total_count	Items the job attempted, including any failed or skipped.
items_succeeded_count	Items successfully backed up.
items_failed_count	Items that failed. A value greater than 0 is a real coverage gap.
items_skipped_count	Items deliberately not backed up. Skipped items are not a failure.

Null is not zero. A null count means "not reported," never zero.

On Shopify, BigCommerce, Intuit and Trello, items_failed_count and items_skipped_count come back null — these integrations report the total and succeeded counts but not the failed/skipped split. On those you can say how many of the attempted items backed up (for example, "24 of 26"), but you can't split a failure into failed-versus-skipped. Jira, Confluence, GitHub and most others report all four counts.

Trello counts boards, not items. On Trello, items_total_count is the number of boards attempted, not cards or attachments. Don't compare a Trello count against another integration's — the units differ.

Filtering

List backups accepts an optional status filter that takes exactly success, failure, or in_progress (note it is failure, not failed).

Account status — List accounts / Get account

An account's backup_status is a different vocabulary. It describes the account's present condition, which includes states that no single job would ever produce:

Value	Meaning
success	The most recent backup completed.
failure	The most recent backup did not complete cleanly.
in_progress	A backup is running right now.
pending	A backup is queued. An account can sit here for a while, so pending is not "healthy."
never	Rewind has never backed this account up.
disabled	Backups are turned off for this account.
in_arrears	Backups are stopped. Despite the name, this is set both for an unpaid balance and when the integration has been uninstalled or disconnected — check both.

Why the two surfaces can differ

They answer different questions. Per-job status is the outcome of one specific job; account backup_status is the account's current condition and can report pending, never, disabled or in_arrears, which are not job outcomes at all. A backup that skipped some items but failed none is a success on both — but if you were reading an older response where a skip-only job showed as failure while the account said success, that mismatch is exactly what these two vocabularies were reconciled to remove.

Monitoring recommendations

• For account-health alerting (e.g. paging when a backup stops working), poll backup_status from List accounts / Get account. It reflects the account's current condition in one field.
• For per-job detail (when did the last backup run, how many items backed up, did anything fail), use List backups and read the item counts.
• Don't drive an alarm off the raw per-job status alone without checking items_failed_count — a failure may be a stopped or invalidated run rather than lost data, and a success may carry skipped items.