
A Crypto Bot Trading Journal You Can Use Every Week
Keep the settings behind the result. This bot journal links launches, executions, changes, and equity snapshots so a weekly review can explain what ran and why the balance changed
You launch a GRID bot, widen its range on Wednesday, add funds on Friday, and restart it after the weekend. The final PnL screenshot contains a result. It does not tell you which setup produced it.
A crypto bot trading journal connects each run to its settings, executions, capital changes, and interventions. That history lets you review the strategy you actually ran, including the edits you made along the way.
Start with four linked records: runs, fills, changes, and account snapshots. You can keep them in a spreadsheet. The editable journal below includes a downloadable JSON backup and CSV exports.
Give every launch a run ID
A run ID identifies one launch. Use something readable, such as DEMO-BTC-GRID-20261102-01. Record the exchange and account alias, pair, bot type, and whether it uses virtual or real funds.
Separate a run ID from a settings version. A restart creates a new run; an in-place configuration edit creates a new version within the existing run. Your journal should preserve both the old and new settings.
Avoid using an API key or account secret as an identifier. A private alias and the relevant exchange transaction references are enough to connect your records.
| Run field | Example | Why it belongs |
|---|---|---|
| Run ID | DEMO-BTC-GRID-20261102-01 | Connects fills and changes to one launch |
| Environment | Demo | Keeps simulated and live outcomes separate |
| Market | BTC/USDT spot | Defines asset and quote units |
| Account alias | Exchange-A-demo | Separates similar markets in different accounts |
| Settings version | v1 | Identifies the rules active at a given time |
| Starting assets | 500 USDT and 0.005 BTC | Preserves the actual opening portfolio |
| Valuation reference | BTC at 100,000 USDT | Explains a 1,000 USDT starting equity |
The numbers above are fictional. Recording starting assets as well as their marked value avoids treating a bot that begins with coins as if it began entirely in cash.

Save the rules in enough detail to reconstruct them
“BTC grid, medium risk” is too vague. Record range boundaries, grid count or spacing convention, starting allocation, and the enabled exit or trailing settings that affect the strategy.
For a DCA setup, save the base order, averaging sizes, price levels, order-size multiplier, and exit definition. For futures, add contract type, position side, leverage, margin mode, and the relevant funding records.
Write a short launch hypothesis. For example: “Observe how this fixed spot range handles repeated movement between these boundaries during a two-week demo run.” Specify what would make you investigate or stop. A boundary breach, balance mismatch, or inability to reconcile fills is more useful than “stop if it feels wrong.”
Keep a screenshot or exported configuration if available, but write the important settings as fields too. Screenshots become difficult to compare after several revisions.
Record fills separately from completed trades
A fill is an execution. An order can receive several fills, and a completed strategy cycle can contain several orders.
| Record | What one row represents |
|---|---|
| Order | One instruction submitted to the venue |
| Fill | One execution against that instruction |
| GRID cycle | The matched buying and selling activity under a stated matching convention |
| DCA position | The base entry, averaging entries, and exits grouped into one position |
Use unique fill IDs and retain the exchange order ID. If you import the same history twice, those identifiers help you detect duplicates.
A count of profitable sell fills does not establish the strategy's win rate. You need a consistent unit of analysis and a rule for matching costs to exits. A DCA position with five entries and one exit cannot be compared with six independent trades by counting rows.
This journal is an operational record. Tax matching and reporting may require different conventions and additional records.
Keep fees in the currency charged
Suppose a fictional buy spends 100 USDT at a price of 100 USDT per coin and incurs a 0.1 USDT fee. Record 1 coin received, 100 USDT trade value, and 0.1 USDT fee.
If the fee is 0.001 coin instead, the received balance is 0.999 coin under that assumption. Converting both fee treatments to “0.1” without a currency loses information.
For a common reporting currency, save the original fee amount and asset alongside the conversion rate, timestamp, and source. Use the same convention throughout the review. Record futures funding as a separate signed cash flow, with a clear rule such as positive for received and negative for paid.
The real bot-performance guide provides context for evaluating results. Your journal supplies the history needed to explain a particular run.
Capital added is a cash flow
Adding 200 USDT to an account can increase its ending value even while the trading strategy loses money. Keep deposits, withdrawals, and internal transfers separate from trading PnL.
For a defined accounting boundary:
Cash-flow-adjusted change = ending equity − starting equity − external deposits + external withdrawals.
Consider a fictional review period:
| Item | Amount |
|---|---|
| Starting equity | 1,000 USDT |
| External deposit | 200 USDT |
| External withdrawals | 0 USDT |
| Ending equity | 1,150 USDT |
| Change after external cash flows | −50 USDT |
The ending balance is 150 USDT higher, but the account lost 50 USDT after allowing for the deposit. This is a cash reconciliation, not a time-weighted or money-weighted return calculation.
Choose the boundary before applying the formula. A transfer from one bot allocation to another is external to each bot but internal to the combined account. Counting it twice distorts the account result. Open inventory, fees, and funding already reflected in ending equity should not be subtracted a second time.
Log every setting change before editing the past
Keep the original run record. Add a change row with the time, old value, new value, reason, and expected effect.
| Time in UTC | Run ID | Change | Reason recorded at the time |
|---|---|---|---|
| Nov 4, 12:00 | DEMO-BTC-GRID-20261102-01 | Range v1 replaced by v2 | Price remained outside the original range; separate review required |
| Nov 6, 09:00 | DEMO-BTC-GRID-20261102-01 | Added 200 virtual USDT | Test the documented funding change |
These are illustrative entries. They demonstrate the record structure rather than recommending a range change or a capital increase.
An after-the-fact reason should carry that label. It is easy to rewrite a losing decision as if you had predicted the outcome. Preserve what you knew when you changed the setup, then add a separate review note later.
An exchange intervention belongs in the change history too. Delisting, ADL, manual liquidation of another hedge leg, or an API interruption can explain behavior that the saved strategy settings alone cannot.
Use the template without creating a maintenance project
Create four tabs or sections:
- Runs: identifiers, market, environment, starting assets, hypothesis, and settings.
- Fills: execution time, run ID, order ID, side, price, quantity, fee amount, and fee currency.
- Changes: time, run ID, settings version, field changed, old value, new value, and reason.
- Snapshots: time, run ID or account boundary, equity, external cash flows, and valuation reference.
The editable journal keeps these records in your browser's local storage when available. That storage is tied to the browser and file origin; it is not cloud sync. Export a JSON backup after each review and keep it with your exchange records. CSV exports are useful for spreadsheet analysis, while the JSON backup preserves all four sections together.
Use one time zone in the journal, preferably UTC. Save original exchange timestamps if an export uses another zone. A funding payment posted near midnight can otherwise land in a different review period from the position that incurred it.
A weekly review that produces a decision
Set a consistent cutoff and take an equity snapshot using a stated price reference. Check for missing fills, duplicate imports, unresolved orders, and unrecorded transfers before interpreting performance.
Then review the run against its hypothesis. Did the market stay within the intended conditions? Did the bot follow the saved settings? Did an intervention change the result? Separate a strategy loss from an execution or recordkeeping problem.
Write one decision with a reason: continue the fixed test, investigate a discrepancy, stop under the original rule, or begin a new version. A short period with a handful of completed cycles gives limited evidence about repeatability. Preserve the record even if the outcome disappoints you.
Your bot journal
One CSV row per record. Use the same run ID across sections. The example uses fictional demo data. Edit the records below and keep the column headings. This template does not connect to an exchange.
Loading local records…
Runs
Fills
Changes
Snapshots
Records are stored locally in this browser when available. They are not synced to an account or another device. Export a backup after each review. Keep API keys, passwords, and personal account details outside the journal.
Practice the full workflow in Bitsgap demo
Launch a supported bot with virtual funds in Bitsgap, save its starting settings, and create your first journal record before changing anything. Use the bot's available trade and performance details alongside exchange records where relevant. The journal remains a separate record of your decisions; this template does not provide automatic account imports.
Frequently asked questions
What should a crypto bot journal track?
Track launches, settings versions, fills, fees, capital movements, and equity snapshots. Link each record to a run ID so you can reconstruct the strategy and its changes.
Can I calculate win rate from completed orders?
Only after defining the trading unit and cost matching. An order, a fill, a GRID cycle, and a DCA position describe different things. Comparing their raw counts produces misleading statistics.
Does the template connect to my exchange?
No. It supports manual records and local exports. Add information from your platform and exchange history, and keep credentials outside the journal.
Should I combine demo and live results?
Keep them separate. Demo helps you practice and observe a setup, while live execution has its own costs, liquidity constraints, and operational outcomes.
Educational content. All sample records and amounts are fictional. A trading journal does not establish that a strategy will be profitable.