Purpose: a small, repeatable log for every configuration or automation change. It is designed to answer one question under pressure: what changed, what evidence says it helped or hurt, and what is the safe next move?
This is an operations worksheet, not a trading signal, a profit promise, or a substitute for Gunbot Support.
Gunbot’s support flow separates setup, exchange connections, trading logic, backtesting, advanced automation (including AutoConfig, custom JavaScript, alerts and REST API), and troubleshooting. That separation is a useful reminder: a change in one area should be observable before it is bundled with another. [1]
Gunbot also provides simulator mode and historical backtests to inspect behavior without live orders. Use those before treating a live configuration change as proven. [1]
Copy this once per change. One card = one hypothesis.
CHANGE ID / TIME:
SCOPE: one pair | one strategy | one AutoConfig rule | one connection
HYPOTHESIS: what behaviour should change, and why?
BEFORE SNAPSHOT
- config/export location:
- strategy + pair state:
- open orders / open position noted:
- relevant logs or alert state saved:
- test evidence (simulator/backtest if applicable):
CHANGE
- exact setting/rule changed:
- expected observable effect:
- what was deliberately left unchanged:
OBSERVATION WINDOW
- start / review time:
- expected events:
- unexpected events or errors:
- compare with the before snapshot:
DECISION
[ ] keep
[ ] revert
[ ] pause and investigate
Reason:
Next owner / next review:
Change one meaningful variable first: for example, one pair, one strategy setting, or one AutoConfig rule. Do not combine an exchange-connection edit, strategy edit and automation-rule change in the same unlogged move. If the outcome changes, you need to know which lever caused it.
Save the current configuration or export location, note relevant open orders and positions, and preserve the log/alert context. The goal is not paperwork; it is making a rollback factual instead of memory-driven.
“Make it better” is useless. Write a checkable statement such as: “This rule should stop applying to pairs that fail the stated filter.” A hypothesis tells you what to look for in logs, alerts and observed bot behaviour.
For trading-logic changes, inspect simulator or historical-backtest behaviour first. Those tools are explicitly part of Gunbot’s support route for testing behaviour without live orders. [1] A backtest does not prove a live result; it only gives evidence worth documenting before a controlled live observation.
At the review time, compare actual events and errors against the before snapshot and hypothesis. If the result is unclear, do not stack another setting on top. Mark the card pause and investigate, then use the focused troubleshooting route or Support.
Use exactly one outcome: keep, revert, or pause and investigate. Record the reason and next owner. A team can then continue from evidence instead of recreating the incident.
A journal does not validate an exchange connection, guarantee fills, prevent market risk, or replace documentation and human support. It simply gives each change a scope, a before state, an observation window and a defensible rollback decision.
Community note: I run Gunbotic.com Community. We share practical setup and operations discussion—not signals and not profit promises. For peer discussion around this worksheet: https://t.me/gunbotic_support
[1] Gunbot Support, “Learn how to work with Gunbot” (accessed 2026-09-16): https://www.gunbot.com/support/ — describes setup, connections, trading logic, simulator/historical backtests, AutoConfig, custom JavaScript, alerts, REST API and troubleshooting.
A config change is only reversible if you can answer four things: what changed, what was true before, what observation would confirm it, and what triggers revert/pause. For Gunbot, I keep one small card per pair/rule/setting and avoid stacking connection + strategy + AutoConfig edits. Simulator/backtest first when it fits; then a defined live review window. I run Gunbotic.com Community—operations discussion, no signals: https://t.me/gunbotic_support
How do you keep bot configuration changes reversible?
My practical answer: one hypothesis per card, a saved before-state, an explicit observation window, then exactly one decision: keep, revert or pause. This avoids the classic “we changed three settings and now nobody knows why behaviour differs” failure. For Gunbot specifically, the official support structure separates trading logic, testing, automation and troubleshooting; I treat that as a cue not to bundle changes. I run Gunbotic.com Community and wrote out the blank card here for anyone who wants to adapt it: https://t.me/gunbotic_support
Gunbot Operator Change Journal is a 10-minute, copyable worksheet for documenting one configuration or AutoConfig change at a time: before snapshot, hypothesis, observation window and keep/revert/pause decision. It uses Gunbot’s official support categories as the source boundary and makes no trading-performance claims.