SHARKRULE / Learn

Trading bot cooldown: when a repeated signal permits another action

A condition that stays true is not a new threshold crossing. A cooldown only imposes a waiting interval; when it expires, it does not create a signal or renew a spending allowance. To understand repeated bot activity, check the condition, the event that starts the timer, the repeat limit and the remaining budget separately.

SharkRule · Reviewed

Separate a condition, a crossing and a waiting interval

Suppose a worksheet tests whether a price is strictly above 100. Readings of 101, 102 and 103 all satisfy that condition. They do not establish three upward crossings. In this guide, an upward crossing means a previous valid reading at or below 100 followed by a valid reading above 100. Equality belongs to the lower side in this explicitly chosen definition.

A repeat policy decides whether another true observation can permit another action. A crossing policy instead needs that transition. A cooldown adds a time requirement to either policy. TradingView’s documentation likewise separates comparison operators from alert frequency; its settings do not establish a SharkRule integration.

Write down what starts a cooldown: a permitted submission, a fill or a completed exit can give different times. Freqtrade, for example, documents a per-pair CooldownPeriod after an exit. That is its own behavior, not a universal definition or evidence of when SharkRule starts its timer.

Define the example before counting signals

All times, prices and amounts below are hypothetical, with no asset or setting recommendation. This paper exercise has one rule and one unnamed Spot pair. Prices are fresh, ordered observations in quote-currency units; times are UTC. We evaluate only the listed observations, and the first row establishes the previous state without creating a crossing. No real orders are placed.

The example permits an entry only on a new upward crossing of 100, at least 120 seconds after the last permitted entry. The exact 120-second boundary qualifies. A permitted entry immediately reserves 25 for purchase value plus 1 for costs, starts the timer and consumes one of at most two entries for this run. The cumulative cap is 60 including those cost allowances. These invented limits are not SharkRule defaults or controls.

A blocked crossing is recorded and discarded, not queued. Every valid observation updates the previous price even while waiting. Rejected candidates do not restart this example’s timer. Assume permissions and all other checks pass and no earlier order outcome is unresolved. The ledger counts permission and reserved spending, not exchange acceptance or fills.

Worked ledger: six true observations, two permitted entries

Hypothetical crossing rule with a 120-second cooldown and two-entry cap
Time UTCPriceAbove 100?New upward crossing?Decision
09:59:5999NoInitial stateNo action
10:00:00101YesYesEntry 1 permitted; reserve 26
10:00:30102YesNoSame true condition; no new event
10:01:0099NoNoBelow threshold again
10:01:30101YesYesOnly 90 seconds elapsed; discard
10:02:00102YesNo120 seconds elapsed, but no new crossing
10:03:0099NoNoBelow threshold again
10:03:30101YesYes210 seconds elapsed; entry 2 permitted; reserve 26
10:06:0099NoNoBelow threshold again
10:06:30101YesYes180 seconds elapsed; count and budget block entry 3

Check the counts and the unchanged budget

The ten observations contain six values above 100 and four upward crossings. Three crossings satisfy the time requirement: 10:00:00 has no earlier entry, 10:03:30 is 210 seconds after entry 1, and 10:06:30 is 180 seconds after entry 2. Only the first two also pass the count and budget checks. Six true observations therefore produce two permitted entries in this worksheet.

Each entry commits 25 + 1 = 26. Two commit 2 × 26 = 52, leaving 60 − 52 = 8. A third would commit 78, exceeding 60 by 18, and would also exceed the two-entry cap. Waiting longer fixes neither problem. The 1-unit allowance is a hypothetical reservation, not an actual exchange fee; real costs and commitments need reconciliation.

At 10:02:00, a different rule based on a continuing true condition could allow its second entry, with the same timer and available limits. Our crossing rule cannot: the 10:01:30 crossing was discarded and 101 → 102 is not another crossing. Storing blocked events for later would be a third policy requiring explicit rules for expiry and revalidation. Do not infer such a queue from a countdown.

Common mistakes when a bot repeats or waits

Treating every poll as a new event multiplies actions while a condition remains true. Conversely, expecting a crossing rule to act immediately after its timer expires overlooks the need for a new transition. A rule that starts while price is already above the threshold also needs an explicit initialization policy; the first reading alone cannot prove a crossing.

A repeated delivery of the same event is different from a later, distinct observation with the same price. Record an event identifier or observation time and the rule version. A cooldown can temporarily hide duplicate delivery, but a delayed duplicate may arrive after it expires. Restarting a tool should not silently erase the prior-event record, timer, entry count or spending commitments.

Do not turn missing data into a false reading that appears to reset the condition. An apparent crossing after a gap needs the rule’s documented data-recovery policy. Crossing logic can also fire repeatedly when observed prices alternate around 100; a cooldown limits timing, not signal quality.

A timeout is not proof of an unsuccessful order. Binance directs users to check an uncertain submission’s status. In SharkRule, unresolved Binance submissions must block further Binance submissions. Keep the original order and spending record while reconciling it; elapsed time alone cannot release that block.

A practical repeat-policy checklist

  1. Name the exchange, pair, input, comparison and evaluation timing. Define equality and the first-observation behavior. Confirm whether you want a continuing condition or a new crossing.
  2. Record the cooldown’s scope: this rule, this pair or the whole account. Record its start event, unit and exact boundary. Do not assume another rule shares the timer.
  3. Specify what happens to a signal during the wait: discard it or retain it under an explicit expiry and recheck policy. Record whether blocked signals restart the timer.
  4. List maximum entries, the cumulative budget, costs and outstanding commitments. Identify when each counter can reset. A restart, timer expiry or sale does not automatically create a new allowance.
  5. Replay a short paper ledger containing a steady true condition, a return below the threshold, a crossing during the wait and one after it. Add a duplicate event, a data gap and an exhausted budget.
  6. Compare expected decisions with the available activity record. Distinguish a blocked candidate, permission to submit, exchange acceptance and fills. Leave unknown outcomes unresolved until checked.

What this check can establish, and your next step

This exercise checks whether a written rule behaves consistently with its own repeat policy. It does not identify a profitable cooldown duration. Waiting can miss moves; repeated actions can accumulate fees and exposure. Slippage, partial fills, non-fills, exchange outages and losses remain possible. A simulation cannot guarantee live execution.

Use the localized SharkRule Binance overview linked in Sources to review the amount per buy and maximum buys shown before an explicit start. It also lists cooldowns for custom rules. Compare the controls actually shown for your Shark with the worksheet; the overview does not establish this example’s timer start, crossing policy or treatment of blocked signals.

Available rules and eligibility depend on the current dashboard, account and location. Connecting an exchange does not start trading. SharkRule is independent software, not affiliated with or endorsed by Binance. We are not financial or investment advisors; this guide explains mechanics, not assets, allocations, position sizes or trades to choose.

Frequently asked questions

Does a cooldown mean only one trade per signal?

Not by itself. It specifies a waiting interval under a stated policy. A continuously true condition may permit another action after the wait, while a crossing-only rule needs another transition. A separate entry cap controls the total count.

What happens to a crossing during the cooldown?

That depends on the documented policy. This example discards it while still updating the previous observation. A system that queues it needs separate expiry and revalidation rules. Do not assume it will execute later.

Does pausing and restarting create a fresh budget?

Do not assume so. Review the saved entry count, outstanding orders and cumulative commitments. If the restart behavior or original order outcome is unknown, the record is incomplete; a new session is not evidence of unused spending room.

Is two minutes the right cooldown?

The 120 seconds here only make the arithmetic visible. No duration is recommended, and fewer actions do not prove better results. First establish what your rule evaluates, what starts its timer and which limits remain in force.

Official documentation and references

Prepared with AI assistance from the linked official documentation. Examples are hypothetical; no live account tests or return comparisons were performed.