To roll back a bad prompt change, confirm which version is live, restore the last known good version through your normal deploy or store, flush any caches, test with your sample inputs, and then record what happened. Speed depends on having versions saved before you need them.
Before the incident
A rollback is fast when three things already exist.
- Every prompt version is stored with author and time.
- The application logs which version served each request.
- A set of test inputs can confirm the old behavior is back.
If you do not have these yet, set them up first. See how to version and review prompt templates in Git.
The runbook
- Declare it. Name an incident lead and a channel. Say what the symptom is, such as wrong format, a refusal that disappeared or an answer that leaks data.
- Contain if needed. If the prompt is exposing data or driving harmful actions, disable the feature or switch to a safe fallback message before analysis. Containment comes before diagnosis.
- Identify the version. Use request logs to find the template version in use, and when it changed. Compare it with the previous one.
- Check the other two inputs. Behavior can also change because the model version or the retrieved documents changed. A quick check saves rolling back the wrong thing. For the three routes, see training data, retrieval corpus or prompt.
- Restore. Revert the commit and deploy, or promote the previous version in your store. Do not hand edit the live text, because the history will then disagree with reality.
- Flush caches. If prompts or responses are cached, clear them so old results do not keep serving.
- Verify. Run the regression inputs against production or a mirror. Check a handful of real requests in logs.
- Communicate. Tell affected teams and, if customers saw bad output, follow your usual customer notice process.
What to check when it did not help
- Another instance still serves the old or new text because of a slow cache refresh.
- The model provider changed the model behind an alias. Pin a specific model version for production calls.
- A per customer or per language variant of the prompt has its own copy that was not reverted.
- The problem is in retrieved content, not the template.
After the rollback
Hold a short, blameless review within a few days.
- How did the change reach production? Was review skipped or did it miss something?
- Which test would have caught it? Add that case to the suite.
- Should this prompt move to a higher risk tier?
- Did the register entry and owner prove accurate?
A single bad edit is rarely the real finding. The finding is usually that the edit path was too easy, or the test set was too thin.
Keep a fallback
For features where a wrong answer is costly, keep a plain fallback, such as a fixed message or a hand off to a person, that you can switch to in seconds while you investigate. That is much faster than debugging with the feature live.
Quick check
Should I rewrite the prompt to fix it forward instead?
Roll back first when you have a known good version, then fix forward with review. Editing under pressure often makes the next incident.
How long should rollback take?
Aim for minutes for a deploy based prompt. If it takes hours, the process, not the prompt, needs work.
Last reviewed: 19 October 2026.