Autosave and drafts

The experiment editor is an explicit save form. Filling in fields does not send anything to ABTestly; you save when you click Save changes (or Save & republish on a running experiment). One thing is kept for you automatically, and it is local to your browser: the JavaScript and CSS you are typing in a variation’s code editor.

​

What is saved automatically

While the code editor is open, your working JS and CSS are mirrored into this browser’s local storage. The mirror is written about 600 ms after you stop typing, and again when you close the pane or leave the page. This mirror is not a save. It never reaches ABTestly and it never republishes anything. It exists so that a refresh, a crash, or a misplaced Cmd+W does not lose the code you were in the middle of writing. You still have to click Save in the code editor.

​

Recovering an unsaved draft

Next time you open that variation’s code editor, if the mirror differs from what is saved on the server, a banner appears above the panes offering to bring your unsaved work back. Two versions of it:

• You have unsaved changes to this variation. The saved code is where you left it. Recover loads your unsaved edits into the panes; Discard throws them away.
• Unsaved changes found, but the saved code has changed. Someone (or you, in another tab) saved this variation since your draft was stashed. The button reads Recover anyway, because taking your draft will overwrite the newer saved code.

Both versions of the banner also offer Compare with saved, a read only comparison of your draft with the code saved now. Comparing never applies the draft. See Review changes. The mirror also keeps the variation’s libraries when your draft changed them, for example after you restore an older version that had different libraries. Recover then puts back the libraries as well as the code. If someone has changed the saved libraries since your draft was stashed, the banner treats it as the second case above. The banner is not a one-time offer. It is recalculated every time you open the code editor, so an unresolved draft keeps being offered until you either Discard it or save. Note that Recover by itself does not clear the mirror; it only loads it into the editor, and the mirror is rewritten as you keep typing. Saving is what settles it. If you have the same experiment open in two tabs, the editor warns you in the second one rather than letting the two drafts overwrite each other.

​

Save-in-flight guard

If you try to close the tab while a save is actually in progress, the browser asks you to confirm first. The wording is your browser’s own, not ours (Chrome says “Changes you made may not be saved”). This guard is armed only during the save request itself. It does not fire for merely unsaved edits, so it is not a safety net for walking away from a half-filled form.

​

Publish outbox

Publishing writes a fresh config for your whole site to Cloudflare KV. If that write fails, the publish is not lost. ABTestly records the intent in an outbox before the write is attempted, and a job running every minute retries it, with a second pass every five minutes as a backstop. There is no attempt limit; it keeps retrying until it succeeds. If you save again while an earlier publish is still outstanding, the two are coalesced rather than queued. There is one outstanding publish per site, and it always rebuilds from your current saved state, so it cannot deliver a stale config or apply your edits out of order.

​

How to tell where a change is

Every successful publish stamps a config version and a publish timestamp, and the version history is kept per site. The outbox row carries the attempt count and the time the publish was first requested. On Site settings, if the most recent publish has already failed at least once, a banner reads:

Saved, but not yet live. Your last change hasn’t reached your site yet. ABTestly is retrying automatically, this usually clears within a few minutes.

Two things to know about that banner. It appears only after a failed attempt, not merely because a publish is in flight, and it is checked when the page loads and after you save rather than polling. Reload the page to re-check. Once a publish succeeds, there is a further delay before visitors see it, because the config is cached. See Schedule for the timings. The experiment detail page has a Republish button if you want to force a fresh attempt yourself.

​

Reset data on a running experiment

If you edit a running or paused experiment in a way that would invalidate its data, and it has collected visitors since its last reset, the save comes back with a 409 data_reset_required and the editor opens a dialog. The changes that trigger it are traffic allocation, audience, variant code, goals, and host scope. Anything else, including the name, the hypothesis, and tags, saves normally. Drafts never trigger it.

• Reset and continue. Start a new epoch. Old data is preserved but the results page starts fresh.
• Keep data and continue. Merge with the existing epoch.
• Cancel. Leave the experiment as it is.

The choice is explicit, so there are no accidental resets and no accidental merges that would blur two versions of your test.

​

What is not kept for you

• Anything outside a variation’s code panes. Name, targeting, goals, traffic split, and schedule live only in the form until you click Save.
• 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. Your variation code draft will be offered back by the recovery banner. Almost every stuck-editor issue is a stale in-memory state that a refresh clears.