When a DCA recurring buy misses an interval, the platform's recovery policy determines whether it is skipped, retried or retained for catch-up. Restoring funds does not prove earlier intervals will be bought. Check each due occurrence against orders and fills, confirm the next scheduled time, and establish any catch-up limit before making an extra purchase.
A daily plan can resume successfully while leaving its owner with fewer purchases than expected. Another system might release several overdue purchases together. Both can display an active plan, yet create different cash demands and purchase timing.
This question concerns scheduled accumulation. The distinction between periodic dollar-cost averaging and price-triggered safety orders matters: an unfilled price level does not become a missed daily contribution. Likewise, a DCA deal-entry queue decides which eligible deal receives capacity; it does not establish whether a recurring schedule retains missed dates.
Find the policy behind the next attempt
Start with the service's current documentation and the specific plan's history. A notification saying “next attempt tomorrow” does not tell you whether tomorrow will buy one normal amount or several accumulated amounts.
Kraken's recurring-order documentation says a failed order produces an email containing the next attempt date. It identifies insufficient account funds, adverse market conditions and system errors as possible causes. For an unmet price condition specifically, it says the order is retried at the next regular scheduled interval.
Binance Japan's Convert Recurring FAQ gives another concrete example: insufficient wallet balance causes the purchase to fail, and the system tries another purchase on the next recurring cycle. These are rules for the named services. Neither passage establishes that all missed amounts are automatically combined into the next purchase.
Ask which of these outcomes applies:
| Recovery rule | Treatment of an earlier missed interval | What to establish |
|---|---|---|
| Skip and continue | Close that occurrence without a purchase | The next occurrence keeps its normal amount |
| Retry the same occurrence | Keep the original occurrence pending | Retry deadline and whether a new occurrence can overlap |
| Retain a catch-up backlog | Preserve overdue amounts for later execution | Oldest eligible date, amount limit and backlog expiry |
| Require a manual decision | Leave a visible shortfall for the owner | How a manual purchase prevents a later automatic duplicate |
The last three require more detail than an active/paused label. A rejected payment, an intentionally paused plan and an order awaiting confirmation can have different recovery paths.
Give each scheduled occurrence its own identity
A useful record separates the plan from its individual due purchases. Retain the plan identifier, schedule revision, amount, asset, funding source, recurrence rule and time zone. For each occurrence, preserve its original due time, attempt history, confirmed spending and final outcome.
“Daily at 09:00 Europe/Berlin” is a more complete schedule than “daily at nine.” The record should also show the corresponding UTC instant. Execution time belongs in another field: a purchase due Saturday and filled Monday remains evidence of Saturday's late occurrence.
These identities matter when an app restarts or a notification arrives twice. The same overdue occurrence should return to its existing record; Monday's genuinely new occurrence needs a separate record even if its amount is identical. The broader trading idempotency guide explains that distinction between repeated delivery and a new trading intent.
Editing the plan adds another question. If the amount changes from 20 to 30 quote units, do retained overdue occurrences keep 20, adopt 30 or expire? Preserve the rule that applied when each occurrence was authorized. Do not reconstruct the backlog by multiplying today's amount by a missing-date count.
Work through a missed weekend
Consider a hypothetical unleveraged plan to spend 20 dollars each day at 09:00 in Europe/Berlin. It misses 24 and 25 October 2026 because spendable cash is unavailable. Before the 26 October purchase, funding becomes available for all four planned contributions through 27 October.
Assume the invented execution prices below, full fills at those prices, a constant-value dollar quote and no fees, spread, slippage or rounding. The prices on missed dates are counterfactual reference prices; no purchase occurred then. This example compares recovery rules, with no forecast of returns.
| Scheduled date | Local due time and UTC offset | Due time in UTC | Illustrative price per unit | Initial result |
|---|---|---|---|---|
| 24 October | 09:00, UTC+02:00 | 07:00 | $100 | Missed |
| 25 October | 09:00, UTC+01:00 | 08:00 | $80 | Missed |
| 26 October | 09:00, UTC+01:00 | 08:00 | $125 | Funding restored |
| 27 October | 09:00, UTC+01:00 | 08:00 | $100 | Next normal date |
Compare three hypothetical recovery policies. The capped policy allows 40 dollars total per day. It reserves 20 dollars for the current contribution, then uses the remaining 20 for the oldest overdue occurrence.
| Policy | Spending on 26 October | Spending on 27 October | Total spent | Units acquired |
|---|---|---|---|---|
| Skip both missed dates | $20 | $20 | $40 | 0.36 |
| Catch up both missed dates immediately | $60 | $20 | $80 | 0.68 |
| Cap total daily spending at $40 | $40 | $40 | $80 | 0.72 |
Immediate catch-up spends 20 + 20 + 20 = $60 on 26 October: two overdue amounts plus the current contribution. Its acquired quantity is 60/125 + 20/100 = 0.68 units.
Under the cap, 24 October's overdue occurrence fills alongside the current purchase on the 26th. The 25 October occurrence remains pending until it fills alongside the current purchase on the 27th. Quantity is 40/125 + 40/100 = 0.72 units. Each original occurrence is satisfied once, with no backlog remaining after the 27th.
Had all four contributions executed on time at the stated reference prices, they would have acquired 20/100 + 20/80 + 20/125 + 20/100 = 0.81 units. Catch-up cannot recreate the unavailable historical prices. The difference between 0.68 and 0.72 also depends entirely on the invented later price path; reversing that path can reverse the comparison.
The skip policy leaves 40 dollars unspent. Comparing only acquired units would hide that different capital deployment. A useful statement therefore shows actual spending, remaining cash and purchased quantity together.
These amounts describe a quote-funded buy plan. For a plan distributing existing assets, the DCA sell-bot versus buy-bot comparison changes the funding question to available base inventory. The same missed-date count can represent a very different instruction.
Check what “daily” means when the clocks change
The example's UTC times were calculated using Python's IANA-backed time-zone library. Its official ZoneInfo documentation demonstrates offset changes across daylight-saving transitions and the ambiguity of a repeated local hour.
In the checked Berlin timeline, 09:00 on 24 October is 07:00 UTC, while 09:00 on the 25th is 08:00 UTC. Those daily local occurrences are 25 elapsed hours apart. A schedule fixed at 07:00 UTC would instead occur at 08:00 Berlin time after the change.
Choose the intended interpretation explicitly: a local calendar time or a fixed elapsed interval. Traveling with a phone should not silently redefine an existing plan's time zone. Inspect the saved schedule rather than relying on the screen's display zone.
A plan near a clock change needs an additional policy. A local time may occur twice in autumn or be absent in spring. Establish whether the scheduler chooses one occurrence, skips the date or shifts execution. A repeated local clock reading alone cannot identify an extra authorized purchase. Verify monthly boundary rules too if the selected day does not exist in every month.
Reconcile the shortfall before a manual purchase
First, establish whether each due occurrence is truly unfilled. A missing success email is weak evidence. Check transaction history and any pending orders or payments. If a submission outcome is unknown, follow the order-timeout reconciliation process before creating a replacement purchase.
Second, distinguish an available balance from money usable by this plan. A deposit may still be pending, the selected wallet may differ from the funded wallet, or other orders may reserve the cash. Include applicable costs when checking whether a catch-up amount is fundable.
Third, write a recovery limit that covers current and overdue purchases together. State how much may be spent per recovery period, which overdue dates remain eligible and what happens when that allowance is exhausted. Restoring a large balance should not itself authorize an unlimited backlog.
Finally, account for manual make-up purchases. Confirm whether the service still intends to retry before buying separately. In a workflow you control, link the manual fill to the specific missed occurrence and resolve its pending instruction. If the service cannot make that association, use its documented cancellation or pause process, then confirm the old purchase is resolved and no retry remains scheduled. Verify the next due occurrence before resuming.
Additional purchases also change holdings and acquisition cost. If those holdings feed a DCA take-profit ladder, reconcile the new sellable quantity and exit allocations after confirmed fills.
For the next missed interval, build a short occurrence ledger: original due time, amount, known fills, pending attempts, recovery rule and next due time. Resolve uncertainty first, then apply the chosen spending limit. A resumed plan is understandable only when every overdue occurrence has an explained outcome.