AI Trading Bot Settings: 8 Checks Before You Edit a Live Bot

DN AI Trading Beginner Series · Reviewed 9 November 2026

You adjust a bot’s settings, press Save and see the new value on screen. What have you established? Perhaps the editor now contains the value you wanted. The questions that remain concern where that value is used, when it becomes relevant and which existing activity it can affect.

This guide is for planning a specific edit and reviewing the evidence afterwards. DN’s signal-data guide already explains saved-alert context, while the bot-logs guide examines the records behind a past decision. Here, the task is prospective: make the intended scope of one change explicit before interpreting a saved configuration as an implemented change.

Which configuration artifact are you changing?

An artifact is simply the particular saved or running item you are inspecting. Give it a clear name before comparing versions.

This table defines the questions in DN’s framework. It does not claim every product exposes each item. The planner deliberately selects only one of the first three surfaces at a time; position-management policy has a separate row, and exchange orders remain outside its comparisons.

1. Name one change and the instance it belongs to

Start with a sentence such as: “For this bot instance, I intend to change this named rule from the documented prior configuration to the proposed configuration.” Keep the actual setting, its units and its purpose in your private change record. Give the shared planner a harmless alias such as EXIT-RULE-A.

Also name the venue, account alias, product or instrument, environment and bot instance. Those five context fields distinguish a test copy from a live instance or one account from another. A bot name on its own may leave the case ambiguous.

Use one change per record. “Improve the strategy” could mean an entry threshold, an exit condition, an order size, a model instruction and a schedule change at once. Those settings may have different application rules. Combining them would make a single “applies to existing positions” answer too broad to interpret.

Define the intended result in operational terms. “Use the changed setting for future entries while retaining the documented management policy for positions already open” is a scope statement. It says nothing about whether the strategy will perform better. If you intend a different result for existing positions, write that separately rather than leaving it implied.

Keep an intended revision alias, but do not make the alias carry the whole explanation. CFG-B is a label for your record; it does not describe the contents or prove that those contents were loaded.

2. Identify the saved or running object behind the Edit button

Read the control in its product context. A chart input, a bot configuration and an individual position can have separate editors. Record which object the control changes before assuming that the visible value represents every downstream component.

TradingView provides a specific example. A running Pine alert retains the script, inputs, main symbol and timeframe captured when it was created. Changing that source context later does not update the existing alert; the documentation describes recreating the alert for the changed context. That is a rule for the saved alert, not a claim about exchange orders. [1]

In 3Commas’ current DCA guide, an active bot has an Edit control, alongside a separate Positions view. The guide does not establish a blanket rule for how every bot edit propagates to already-open positions. [2]

A separate 3Commas guide documents position-level editing for Signal Bot and API-request positions. Treat that as a distinct documented control, without inferring that every bot-level setting is isolated from it. [3]

For your record, select the artifact you actually inspected. An editor screenshot belongs in the editor category. A saved-alert record belongs in saved trigger. A runtime report belongs in running instance. The strength of the description comes from naming its boundary accurately.

3. Check which configuration source has priority

When several sources can set the same value, identify which one wins. A file can contain the intended edit while another configuration source supplies the value used by the process. Ask about command-line options, environment settings, imported files and strategy defaults where the product supports them.

Freqtrade documents a priority order that places command-line options above environment variables, which override corresponding configuration or strategy values. It also provides show-config to inspect the combined configuration. Its imported-file rules need their own reading; “the file I edited wins” is not a sufficient explanation. [4]

A combined configuration produced for one invocation still needs context. Record which instance, files and launch environment the inspection represents. Do not automatically relabel a separately generated configuration report as evidence from the running bot.

Keep the comparison small. You need the relevant setting and its effective source, not every unrelated option. If the interface exposes only a configuration name without the value or source, record that limit. A revision label can help locate evidence, but label equality is not a content comparison.

This check is especially useful when an edit appears to have no effect. Preserve the observation first. A competing configuration source is a question to investigate, not a diagnosis the planner can infer from the mismatch.

4. Find the documented activation step

Distinguish writing a value from the operation that makes a component load or capture it. The relevant mechanism might be a product-specific save operation, a replacement saved trigger or a documented configuration reload. Use the mechanism for the exact component and version you are operating.

Freqtrade’s FAQ describes /reload_config as a lifecycle that stops the bot, loads its configuration and strategy, then restarts with them. The word “reload” therefore should not be interpreted as a promise of uninterrupted operation. [5]

Before any planned activation, identify what evidence would establish the reported transition: a relevant configuration report, a retained change record or another documented observation. Keep the prior record available so you can state what changed. A later explanation of what should have happened has a different evidential role.

Also identify who owns existing position management during the proposed transition. This article does not supply a universal stop, restart or cancel sequence. The bot-exit checklist addresses authority and management handoffs when a component is being retired or replaced.

If the activation mechanism or its effect is unclear, leave that part unresolved. Repeating an edit or restart does not turn a missing explanation into evidence. A narrowly framed product-support question can be more useful than another attempt at the same ambiguous action.

5. Separate future entries from existing position management

Write two expectations. The first concerns future entries: should they use the changed setting? The second concerns positions already being managed: should their management use the change or retain the prior setting? Your intention and the product’s documented policy are separate fields in each row.

There are setting-specific rules worth checking. Freqtrade documents that changing stoploss in the configuration or strategy and reloading can apply the new value to open trades, with corresponding logs. It also gives an explicit limitation: the value cannot be changed this way when trailing stop is enabled and has already adjusted the stoploss. Keep that condition attached to the rule. [6]

This example does not establish how another setting or provider behaves. It demonstrates why “existing positions keep everything” and “existing positions receive everything” are both too broad as general assumptions.

In the planner, compare each intended policy with the policy reported by your evidence. “Apply” versus “retain” is a declared conflict even if the configuration labels match. Two matching declarations describe agreement about the policy; they do not prove implementation.

Do not select “retain” merely because you lack evidence of an update. Unknown remains unknown. If no position is currently open, that absence also does not establish the policy that would apply to an existing position. Preserve the scope of the question instead of inventing a no-effect result.

6. Keep product routes, conditions and exceptions attached

Read application rules at the level of the actual setting and route. A feature available in a platform is not automatically enabled in your bot. A control documented for one signal source may have a different interface or scope in another.

The 3Commas Best Bid/Ask guide offers a useful example. For that feature’s rollout, it says existing bots and positions are unchanged and Market remains the default. It separately limits the TradingView Strategy Signal Bot route to entries, configured through the JSON message. These are feature- and route-specific statements, not a general rule for all settings changes. [7]

Capture the qualification in plain language: which product, which setting, which entry or exit route, and which position condition? A support answer about one bot type should retain that bot type in your record. If the answer covers only new entries, it cannot settle the existing-position row.

When a rule is conditional or mixed, narrow the case. You might need separate records for different settings or position conditions. Do not choose a definite policy simply to make the worksheet look complete.

The planner deliberately keeps conditional application unresolved even when both selectors say “conditional.” Two identical conditional labels still omit the conditions needed to determine a particular case. The useful next step is to specify and support the narrower case, not to convert the matching words into an approval.

7. Rehearse the observation you will need

Prepare a small rehearsal around the named change. Define the starting configuration, the intended artifact and the observation you expect after the documented activation step. Use an appropriate test or paper environment where available, and retain its environment label in the record.

The purpose here is to check the change procedure and the evidence it exposes. A rehearsal can reveal that you inspected the wrong artifact, missed a configuration source or cannot obtain the application information you expected. It does not establish the behavior of a separate live instance or certify trading results.

Keep one relevant before-and-after record for the selected artifact. Include the setting name and units in your private notes, the revision aliases, the product route and a pointer to the retained observation. For the two application-policy rows, keep separate supporting references if they rely on different documentation or observations.

Use redacted aliases in the public worksheet. Keep API credentials, webhook secrets, private account identifiers and complete raw configuration files out of its fields and shared exports. The tool does not inspect source files or remove secrets for you.

DN’s paper-to-live checks cover the broader review of affected controls. Here, the rehearsal stays focused on whether this one proposed change can be described and observed at the intended layer.

8. Preserve discrepancies and make the support question specific

After inspecting the relevant record, write down both what it reports and what remains unresolved. An equal revision label, a different context and a position-policy conflict can coexist. Do not hide one finding because another part of the change record looks reassuring.

A useful support question names the product and version, the specific setting, the selected artifact, the documented activation mechanism and your intended scope. Then ask separately what applies to future entries and to existing position management, including conditions and any additional position-level action the product requires.

Attach a redacted evidence reference and describe the discrepancy precisely. For example: “The selected runtime record reports the intended revision, but the available application policy says existing management retains its prior setting. Does this named setting have an exception for this position condition?” That question can be investigated without claiming the edit failed or succeeded.

If you need to restore a previous configuration, treat restoration as another change whose application scope requires checking. Do not infer that returning a label to its prior value reverses any intervening orders or account activity.

Use the position-drift guide for differences in holdings and the orphan-orders guide for working orders whose management is unclear. The settings record helps state the configuration question; it does not reconcile those account states.

Worked example: the revision matches, but one policy conflicts

The examples are fictional teaching records. They use VENUE-A / ACCOUNT-A / SPOT:BASE/QUOTE / TEST-A / INSTANCE-A, with the named change EXIT-RULE-A. These aliases do not describe a provider or a recommended strategy.

In the runtime-conflict case, both the intended revision and the selected runtime record say CFG-B. The declared context agrees and the reader supplies OBS-A as a current-record reference. That supports a scoped comparison of the entered labels, not verified deployment or content equality.

For future entries, the intended and reported policies both say to apply the changed setting. For existing position management, the intention says apply while the reported policy says retain. The first row shows declared policy agreement; the second preserves a declared conflict. The matching runtime label does not settle that conflict.

The other cases cover an editor match with application unknown, a saved trigger reporting CFG-A, conditional application, equal labels from a different context, and a later explanation alongside a policy conflict. The tool does not interpret the letters in those aliases as a chronology or map any fixture to a real platform.

Methodology and limits

DN designed the planner as a deterministic comparison of reader-entered declarations. It compares exact, case-sensitive revision labels for one selected artifact, reports context and evidence basis separately, and compares two application-policy rows. Unknown, conditional and conflicting information retain distinct meanings.

The six dataset cases are synthetic. They demonstrate comparison behavior rather than measured product behavior. The source examples elsewhere in this article retain their named product, setting and route; the model does not automatically translate those examples into a policy for your bot.

The planner cannot inspect configuration contents, verify a claimed revision, establish current deployment, amend orders or determine whether a strategy is profitable. An evidence alias is a pointer supplied by the reader, not an authentication check. Already-working exchange orders and their ownership remain outside its model.

Frequently asked questions

Primary sources

Official documentation reviewed on 9 November 2026 (SAST). Product, setting, evidence surface and application scope matter. These are documentation findings, not verified account behavior.

1. Alerts — TradingView Pine Script
2. How the DCA Bot Works: Strategy & Setup Guide — 3Commas
3. Positions Tab Overview (Signal Bot, API) — 3Commas
4. Configuration — Freqtrade stable documentation
5. FAQ: configuration reload — Freqtrade stable documentation
6. Stoploss: changing open trades — Freqtrade stable documentation
7. How Best Bid/Ask limit orders work — 3Commas
8. TradingView Features
9. 3Commas: Crypto Trading Bots & Automation Platform