A DCA bot cooldown between deals delays the next permitted entry after a defined event, usually a completed deal. Check the timer's starting event, units and scope before choosing a duration. Expiry only removes one entry restriction: the bot still needs a valid signal, available capital and permission to trade. A cooldown does not close existing exposure or guarantee a better next entry.
The practical question is not simply how many minutes to wait. It is what the bot is waiting for, which activity remains possible and what evidence lets a new cycle begin.
Identify the event that starts the clock
Two controls can both be called cooldown while measuring different intervals:
| Timer definition | Starting event | What the interval measures |
|---|---|---|
| Close-to-start | Previous deal has finished | Waiting after an exit before another entry |
| Start-to-start | Previous deal opened | Minimum spacing between openings |
| Loss-triggered pause | A specified loss condition occurs | Waiting after a risk event |
| Entry delay | An entry condition becomes eligible | Waiting before submitting that particular entry |
These distinctions exist in real documentation. Freqtrade's CooldownPeriod reference describes a pair lock after exiting. In contrast, Cornix's Signals Bot advanced settings define their per-symbol cooldown as an interval between trade openings, measured in seconds. Those are examples of those products' rules, not interchangeable definitions for every DCA bot.
If a trade opens at 10:00 and closes at 10:12, a 20-minute start-to-start restriction reaches its deadline at 10:20. A 20-minute close-to-start restriction reaches it at 10:32. Copying the number without the anchor changes the strategy.
Also establish what counts as finished. A take-profit condition becoming true, an exit request being sent and an entire position actually closing are different events. The timer should follow the implementation's recorded event; your review should establish that event's relationship to actual fills.
Work through a complete waiting interval
Consider a hypothetical unleveraged spot bot that permits only one deal for a pair at a time. Its rule is a 20-minute wait after the full previous deal closes. It evaluates fresh entry conditions at five-minute boundaries. The example assumes an exact UTC clock, no outages and that a permitted order can be submitted promptly; it does not assume a guaranteed fill.
| UTC time | Observed event | Entry decision |
|---|---|---|
| 10:00 | First deal opens | Deal is active |
| 10:12 | Final exit fill closes that deal | Record close; wait until 10:32 |
| 10:20 | Entry condition is true | Blocked by cooldown |
| 10:30 | Entry condition is still true | Still blocked |
| 10:32 | Twenty-minute deadline passes | No scheduled evaluation at this instant |
| 10:35 | Fresh condition is false | No entry despite elapsed wait |
| 10:40 | Fresh condition is true and other checks pass | Entry may be submitted |
The arithmetic is 10:12 + 20 minutes = 10:32. The next submission opportunity in this sequence is 10:40, which is 28 minutes after the close. A displayed 20-minute cooldown therefore does not promise another deal exactly 20 minutes later.
The five-minute schedule is an explicit assumption for this worksheet. Some systems check more frequently, while others round lock deadlines to candle boundaries. Freqtrade documents candle rounding for its protections. Check the actual decision clock before comparing a replay with a live event log.
Do not silently carry the true 10:20 signal forward to 10:40. If your rules intentionally queue signals, define their expiry and revalidation. Otherwise, the signal that once justified an entry may no longer exist when the timer permits it. The entry-filter decision contract separates a crossing event from a condition that remains true while the bot waits.
Write a cooldown specification before changing the value
A reusable record needs more than a duration. Complete this worksheet for the particular bot, connection and market:
| Field | Example answer for the constructed bot |
|---|---|
| Anchor | Final recorded close of a completed deal |
| Duration and units | 20 minutes, equivalent to 1,200 seconds |
| Scope | This pair in this bot |
| Activity blocked | New base deals |
| Activity retained | Management of any existing position under separate rules |
| Decision schedule | Five-minute entry evaluations |
| Signal after unlock | Recalculate; discard expired earlier signals |
| Restart behavior | Restore the recorded deadline rather than erase it |
| Evidence | Close fill, stored deadline, blocked decision and next evaluation |
The last two rows are requirements to verify, not assumed capabilities of a platform. If restarting a process clears its waiting state, the saved duration does not describe the behavior you thought you configured.
For KLINEO, the examined DCA form exposes both Cooldown minutes and Cooldown between trades (sec). In the examined spot engine and replay calculations, the longer configured duration governs the post-cycle wait rather than their sum. That code review does not establish identical behavior for every venue or execution path. Review the saved configuration through the DCA configuration guide, then inspect the resulting timing in your intended environment.
Keep time, capital and concurrency separate
A per-pair cooldown may leave every other pair eligible. A per-bot cooldown may leave another bot or manual trade free to enter the same market. State the boundary explicitly instead of interpreting a quiet bot as a quiet account.
Likewise, a waiting interval does not reserve the cash needed for a full averaging ladder. Several pairs can become eligible together after their timers expire. The max-active-deals worksheet addresses how many deals may overlap, while DCA capital requirements addresses what their complete commitments could require. Both checks remain necessary after a cooldown passes.
Do not apply the inter-deal timer to safety orders unless that is the explicitly documented rule. An existing deal can still need averaging, stop or exit management. Delaying those actions because new entries are cooling down would create a different strategy and potentially a different risk. The base-order versus safety-order sizing comparison shows how much exposure can still depend on those later purchases.
Test cases that expose a misleading timer
Test more than the clean take-profit cycle. A partial exit is particularly useful: suppose an exit sells six of ten units while four remain. If the bot treats the first fill as a completed deal and starts another purchase, it may overlap exposure despite your one-deal intention. Track the remaining quantity and the recorded close event together.
A timeout creates another ambiguity. If the final exit's outcome is unknown, neither an assumed close nor an assumed failed close is sufficient evidence. Reconcile the exchange state before restarting entries; the order-timeout reconciliation guide explains that process.
Also test a restart during the wait, a signal one second before expiry, a signal immediately after expiry and a second pair becoming eligible at the same time. Record why each attempt was blocked or allowed. If a risk pause also applies, test both restrictions together: clearing the time lock should not silently clear the risk restriction.
Pausing a bot is a separate action with its own remaining-order questions. The pause-versus-close guide explains why a stopped label cannot establish that inventory disappeared.
Evaluate a duration without inventing an optimum
Choose a small set of candidate waits before looking at their results, then compare them under the same sizing, data, costs and other rules. Include the no-cooldown case when supported. Count blocked signals, completed cycles, time exposed, costs, open positions and total equity at the common endpoint. Fewer trades or a higher win rate alone does not establish an improvement.
A longer wait can skip repeated entries in one noisy episode; it can also miss a favorable move. It cannot prevent the next eligible deal from losing. Selecting the best-looking duration from many trials adds another fitted parameter. Keep the trial record and use a later evaluation period, as described in the walk-forward testing guide.
The outcome of the review should be a specific rule you can reproduce: “After this pair's completed close, block new base entries for this duration, then evaluate current conditions again.” That statement is useful even when the evidence says the strategy should remain in testing.
Editorial method: This AI-assisted article compares primary product documentation and examined KLINEO code with an original timestamp worksheet. It does not report live trading results or identify an optimal cooldown.