> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abtestly.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Autosave and drafts

> Everything you type is saved. If the browser crashes, you can recover. If a publish fails mid-flight, it retries in the background.

The experiment editor autosaves. You do not have to think about it.
Three underlying pieces make sure you do not lose work:

## Autosave

Every field, every keystroke, debounced to a save call every few
hundred ms. The **Save changes** button at the top rarely does
anything new; it exists mostly for the reassurance of a green check.

## Draft recovery

If the browser tab crashes or you close it in the middle of typing,
the editor stashes your unsaved state in localStorage. Next time you
open the experiment, a **Draft recovery** banner offers to restore
your unsaved edits.

* **Restore**, merge the stashed state with the server draft.
* **Discard**, throw away the stashed edits.

The banner appears once. Ignore it and it is gone; the recovery
state persists for a few minutes on the assumption you are coming
right back.

## Save-in-flight guard

If you close the tab while a save is still in flight, the browser
warns you first: "Changes you made may not be saved." Do not lose
work to a stray Cmd+W.

## Publish outbox

Publishing an experiment writes a fresh config to Cloudflare KV. If
that write fails on the network, a transient error, a Cloudflare
blip, the publish is not lost. It goes into an **outbox** and the
worker retries in the background until it succeeds.

**What you see on your side:**

* Publish click returns immediately.
* If the KV write is still pending after a moment, the experiment
  detail page shows a small "Saved, but publishing…" banner.
* The banner stays until the write completes. If it takes longer than
  a few minutes, it means we need to look at the queue, please tell
  us.

Because of the outbox, a failed publish never leaves you in a
"changed but not live" state. Either the change goes live or the
banner tells you it is still trying.

## Reset data on a running experiment

If you edit a running experiment in a way that would invalidate its
data (change targeting, change variants, add/remove a goal), the
save gets a `409 data_reset_required` from the server. The editor
opens a dialog:

* **Reset data and save.** Start a new epoch. Old data is preserved
  but the results page starts fresh.
* **Keep data and save.** Merge with the existing epoch. Only
  available for safe changes (rename, description edit).

The choice is explicit, no accidental resets, no accidental data
merges that would blur two versions of your test.

## What is *not* autosaved

* **Draft variant code inside the editor pane while you are typing.**
  Debounced to a save every second or so; if the tab crashes in the
  middle of an unsaved edit inside the code pane, that edit is what
  the draft-recovery banner offers to restore.
* **The active state of a modal.** Clones you started but did not
  save, the "Are you sure?" dialogs, the schedule picker's
  in-progress date. Those live only in the current tab.

## When something feels off

If the editor feels sticky, a change appears not to persist, or a
save button greys out and never comes back, refresh the page. The
draft recovery banner will offer the latest local state. Almost
every stuck-editor issue is a stale in-memory state that a refresh
clears.