OPTIMIZING is not a stall — it means a copy A/B test is running on that SKU. Copy Crafter runs 14-day tests by default: original copy against a rewritten variant, resolved on real conversion data. Most tests end on schedule. Yours didn't, and there are exactly three common reasons.
The three reasons a test runs long
- Traffic is too low to resolve. The test needs enough sessions per variant to call a winner. A slow-moving SKU can take well past 14 days to reach significance, and the test waits rather than guessing.
- A variant was edited mid-test. Any manual edit to the copy under test restarts the clock — the old data no longer describes what's live, so the test starts measuring again from zero.
- The product's tier changed mid-test. A cost-confidence tier change alters what actions are allowed on the SKU, and the test re-evaluates under the new constraints.
How to resolve it
Open the test drill-down on the Optimizations page. It shows sessions per variant, the current confidence level, and any restart events with their cause. From there you have two levers: end the test manually and keep whichever variant you prefer, or drive traffic to the product so the test can resolve on its own. Manual resolution is logged like any other decision — you'll see who ended it and what was kept.
Why it's never silently force-moved
Every state change on a SKU is gated by ALLOWED_TRANSITIONS, the static map of legal lifecycle moves. There is no code path that yanks a SKU out of OPTIMIZING because a timer expired. A stuck SKU stays visibly stuck, with the reason inspectable, until either the test resolves or an operator decides. That's deliberate: a silent force-move would mean the system overrode an experiment without telling you.
A test that won't resolve is information. Low traffic on a SKU is itself a finding — sometimes the right call isn't better copy, it's asking why nobody lands on the page.