What does a recurring buy actually repeat?
A fixed recurring purchase uses a chosen amount and interval. The calendar makes an occurrence due; balance, permissions, product limits and execution still matter. A price-triggered averaging rule instead waits for a market condition. The label ‘DCA bot’ alone does not tell you which behavior applies, whether amounts change, or whether selling is included.
This guide examines scheduled Spot purchases, not leverage or increasing orders after losses. A buying schedule does not authorize selling. Any optional exit needs its own exact conditions, amount and approval. Neither repeating a purchase nor averaging its cost establishes a favorable future price.
Check the first purchase separately from the next one
Record the first execution, interval, timezone, end condition and policy for missed occurrences. ‘Weekly’ alone does not say whether setup buys immediately or waits. Check the displayed next occurrence and whether execution is at an exact time or within a window. Do not infer local-clock behavior from a UTC timestamp.
Coinbase’s recurring-buy help describes an immediate initial purchase. Its consumer Coinbase instructions are not evidence of Coinbase Advanced or SharkRule scheduling behavior. Review the actual product before approving a plan.
Distinguish a limit on attempts from a limit on completed purchases. A failed attempt may consume the former but not the latter, depending on the documented rule. An indefinite schedule also needs a defined spending period and stop condition; a small per-purchase amount is not a total cap.
A skipped occurrence is different from an unknown order
Available balance is the amount usable by this purchase, not the value of all holdings. Other open orders, account holds or the selected payment source can make the usable amount smaller. Check the correct wallet and currency without assuming a scheduled plan reserves funds in advance.
Binance Convert’s recurring FAQ says an insufficient balance causes failure and another attempt on the next cycle. It does not promise a doubled catch-up purchase. Binance Spot documentation separately warns that a timeout can leave execution unknown and requires a status check. These are different products, not interchangeable retry rules.
In SharkRule, an unresolved Binance submission must continue to block further Binance submissions. A calendar date, restart or other exchange’s status cannot resolve that record.
| Recorded state | What it establishes | What to check next |
|---|---|---|
| Blocked before submission | No order was sent for this occurrence | Reason, available balance and next scheduled time |
| Confirmed rejection with no fills | That order bought nothing | Final order record and any actual charges |
| Timeout or missing response | The outcome is unknown | Original order status and fills; retain its commitment |
| Accepted or partly filled | An order or remaining quantity may still be active | Filled amount, open remainder and costs |
| Confirmed complete | The purchase and costs can be reconciled | Cumulative spending and remaining allowance |
Worked ledger: four scheduled dates do not mean four buys
This original paper example uses four weekly occurrences at 09:00 UTC on 5, 12, 19 and 26 October 2026. The dates are hypothetical, including the future occurrence; no account was tested. By definition, setup makes no immediate purchase, missed occurrences are discarded, and an unresolved order blocks new submissions. These are example policies, not SharkRule defaults or exchange promises.
Each permitted purchase commits 30 generic quote-currency units plus 1 unit reserved for costs. The cumulative cap is 100 for the entire four-date run. Assume each successful purchase ultimately costs exactly 31 including costs; the 1-unit figure is invented, not a quoted fee. There is no sale, automatic funding or budget reset. Four dates offer four opportunities to check, not permission to spend 4 × 31 = 124.
The skipped 12 October occurrence spent zero, but it did not add 31 to the cap. While the 19 October order is unknown, room is 100 − 31 − 31 = 38. A positive remainder does not remove the unresolved-order block. When that order is confirmed complete, move 31 from committed to spent; do not count it twice.
After the ordinary 26 October purchase, spending is 3 × 31 = 93 and room is 100 − 93 = 7. An extra catch-up purchase would require 93 + 31 = 124, exceeding the cap by 24. The exercise blocks it; it does not raise the cap, choose a smaller purchase or renew the run. Actual costs above the allowance would require a fresh check before any later purchase.
| Occurrence / event | Decision or evidence | Spent | Unresolved commitment | Room within 100 |
|---|---|---|---|---|
| 5 Oct, 09:00 UTC | Purchase complete, costs reconciled | 31 | 0 | 69 |
| 12 Oct, 09:00 UTC | Only 20 available; skip before submission | 31 | 0 | 69 |
| 19 Oct, 09:00 UTC | 31 reserved; submission times out | 31 | 31 | 38 |
| 19 Oct, outcome still unknown | No retry or extra catch-up order | 31 | 31 | 38 |
| 19 Oct, later status check | Original purchase completed for 31 | 62 | 0 | 38 |
| 26 Oct, 09:00 UTC | Next ordinary purchase completes for 31 | 93 | 0 | 7 |
| After the four dates | Proposed extra 31 is blocked | 93 | 0 | 7 |
Write down whether a failure is skipped, retried or carried forward
A retry concerns the same occurrence after its failure has been established. The next scheduled occurrence is a separate event. Catch-up is an additional or enlarged later purchase intended to replace a missed one. These choices change timing and possible spending; none follows automatically from the word ‘recurring’.
If the product supports retries, check their maximum count, expiry, original-occurrence identity and balance/cost checks. Keep every retry within the same approved amount and cumulative cap. Never treat a timeout as proof that a new order is safe. Before carrying a missed purchase forward, the policy must explicitly permit it and all current limits must still pass.
A partial fill also needs reconciliation: a new full-size purchase could duplicate the filled portion while the remainder is still open. Cancelling a schedule is not evidence that its already-submitted orders were cancelled or that its existing holdings were sold.
Common mistakes that make a schedule spend differently
Counting only the nominal scheduled dates can overlook an immediate setup purchase. Recreating a plan without checking the old one can leave two schedules active. Counting a new application session as a new budget can erase the very limit the user approved.
Treating ‘insufficient balance’ as an instruction to add money or double the next amount changes the decision instead of diagnosing it. An exchange minimum can also exceed the amount allowed by a rule; the remedy is not an automatic increase. Review the reason and leave an unsupported or incomplete instruction unapproved.
A fixed spending amount does not buy a fixed asset quantity. Prices and conversion quotes change; fees, spread and slippage affect what is received. Scheduling cannot guarantee execution, prevent losses or remove exchange and custody risk. A missed purchase is not evidence that making it up would be beneficial.
A practical schedule review checklist
- Name the account, exact Spot pair or conversion product, amount and currency. Distinguish exchange-native recurrence from an external automation rule.
- Check the first purchase, next occurrence, timezone, interval, final date or count, and whether a missed occurrence is discarded. Record what each counter counts.
- Define the cumulative spending period, cost treatment and outstanding-order commitments. Include any immediate setup purchase and other active schedules in the review.
- Inspect the failed occurrence’s record. Separate never submitted, confirmed rejected, partly filled and unknown; reconcile unknown orders before another submission.
- Check the documented retry and catch-up policy. Confirm that neither restarts the cap, silently enlarges the amount or acts on an expired occurrence.
- Walk through one skipped occurrence, an unknown outcome and a final purchase with little budget left. Compare the expected decisions with the controls actually shown before any explicit start.
Use the ledger to review a rule’s budget
Next, use the localized SharkRule spending-controls guide linked in Sources to compare per-order limits, cumulative spending and outstanding commitments with your rule. The public product requires review of the action and limits before activation; this article does not verify a particular schedule, retry or catch-up feature. Leave missing behavior unapproved.
Availability depends on the current dashboard, account and location. New live activation is not open; the initial customer release is being prepared for eligible UK residents using Coinbase Advanced Spot. A paper exercise or supported simulation cannot establish live fills or returns. SharkRule is independent software, not affiliated with or endorsed by the exchanges. We are not financial or investment advisors; this is education about mechanics, not assets, allocations or trades to choose.
Frequently asked questions
Does the next purchase automatically include a missed one?
Do not assume so. A next-cycle attempt and a catch-up purchase are different policies. Check the product’s documented behavior; any extra purchase still needs permission and room within the unchanged spending cap.
Is an order timeout a failed recurring buy?
It may leave the outcome unknown. Keep the original commitment and check the exchange’s order and fill records before considering another submission. A missing response alone does not prove that nothing was bought.
Does pausing the schedule sell what it already bought?
No selling permission follows from a pause. Check open orders separately, and do not confuse stopping future occurrences with cancelling submitted orders or disposing of existing holdings.
Is a DCA bot the same as a recurring buy?
The label is not precise enough. Inspect whether time or price triggers an action, whether amounts remain fixed, how missed occurrences are handled and whether an exit is separately authorized. No label promises a better result.
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.
- Coinbase consumer help: recurring buys and the initial purchase
https://help.coinbase.com/en-gb/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-can-i-create-or-cancel-a-recurring-transaction - Binance Convert: recurring purchases and insufficient balance
https://www.binance.com/en/support/faq/detail/5026705ac87942069b1bdcf5a99ffc48 - Binance Spot: unknown execution status after a timeout
https://developers.binance.com/en/docs/products/spot/rest-api - SharkRule: review per-order, cumulative and account limits
https://sharkrule.com/learn/trading-bot-risk-controls/ - SharkRule: current product and eligibility
https://sharkrule.com/