Scheduling

Quick answer: Scheduling is the automated triggering of trading tasks at precise times using cron or a scheduler, made market-aware through trading-hours and holiday logic, orderly warm-up and shutdown routines, and reliable clock synchronisation.

In simple words

Scheduling is what makes your system do the right thing at the right moment without you starting it manually. It launches the pre-market preparation, keeps the live loop running only during trading hours, skips holidays, and shuts down cleanly at the close. Because trading is time-sensitive, the schedule has to know the market's calendar and your computer's clock has to be accurate.

Purpose

Scheduling exists so that an automated system runs unattended and on time — warming up before the open, acting only when the market is live, and shutting down safely — rather than depending on a human to press start and stop each day.

Professional explanation

Cron and schedulers

The classic tool is cron, which triggers a command at times specified by a five-field expression (minute, hour, day-of-month, month, day-of-week); a scheduler like a systemd timer, a cloud scheduler, or an in-process scheduling library does the same job with more control. Cron is simple and reliable for coarse timing — start the pre-market job at a fixed time each weekday — but it is calendar-naive: it does not know about exchange holidays or that the market opens at a specific local time, and it happily fires on a day the exchange is closed. So cron typically handles the crude when, while the job itself applies the market-aware logic to decide whether to actually proceed. Overlap protection matters too: guard against a slow run still executing when the next trigger fires.

Market-hours awareness

A trading system must act only when the market is in the right session, so schedules are gated by trading hours rather than wall-clock alone. The system needs to know the pre-open session, the continuous session (illustratively 9:15 to 15:30 for NSE equities), and any post-close windows, and to behave differently in each. Placing a normal order at 15:29 versus 15:31 is the difference between a fill and a rejection. Hardcoding these times is fragile; the robust approach is a session calendar the code consults, so that a change in market timing is a data change, not a code change. The schedule should also distinguish segments — equity, F&O and commodity sessions differ.

Holidays and the trading calendar

Exchanges close on numerous holidays that do not follow a simple weekly pattern, and some days are partial or special sessions (a rare Saturday session, or a Muhurat trading window). A scheduler that assumes every weekday is a trading day will wake up, prepare, and either idle uselessly or, worse, attempt actions the exchange rejects. The correct design maintains an exchange holiday calendar — ideally sourced or updated from the exchange rather than hand-typed — and every scheduled job first checks is-today-a-trading-day before doing anything. This single guard prevents a large class of holiday-related misbehaviour, including chasing a data feed that is silent because the market is shut.

Warm-up routines

A system cannot go from cold to trading instantly; it needs a warm-up phase before the open. Warm-up typically includes: authenticating and obtaining the day's access token, loading the instrument master and any contracts that change (F&O expiries roll), fetching the previous session's positions and open orders to reconcile state, pre-loading historical data so indicators have enough history to compute (an indicator needing 20 bars cannot act on bar one), subscribing to the market-data stream, and running self-checks (connectivity, funds, risk limits). Sequencing this deterministically before the first tick means the strategy is fully primed at the open rather than making decisions on incomplete state.

Shutdown routines

Just as important is a clean shutdown at or before the close. A graceful end-of-day routine cancels any resting orders that should not carry over, squares off intraday (MIS) positions if the strategy requires it before the exchange's auto-square-off, persists state and the day's logs, closes stream connections, and produces a reconciliation report. An abrupt kill instead of a graceful shutdown can leave orders resting, positions unmanaged overnight, or state unpersisted, so the shutdown path deserves the same care as startup. The system should also handle unexpected shutdowns (a crash) by reconciling on the next startup rather than assuming a clean prior exit.

Time synchronisation

Every schedule and timestamp depends on the clock being correct. A machine whose clock has drifted by even a few seconds can trigger jobs late, misjudge whether the market is open, and — critically — attach wrong timestamps to orders and logs, which corrupts reconciliation and any latency measurement. The standard remedy is to synchronise the system clock continuously via NTP, and to be explicit about time zones: store and reason in a defined zone (India Standard Time for NSE, or UTC internally with conversion at the edges) so that daylight-saving assumptions in libraries never silently shift your session boundaries. Never trust an unsynchronised local clock for anything time-sensitive.

Cron vs a market-aware scheduler

Practical example

Advantages

• Runs the system unattended and on time, day after day
• Market-aware gating prevents acting on holidays or outside session hours
• Deterministic warm-up ensures the strategy is fully primed at the open
• Graceful shutdown avoids stranded orders and unmanaged overnight positions

Limitations

• Plain cron is calendar-naive and will fire on holidays without extra guards
• Holiday and session calendars must be maintained and updated as the exchange changes them
• Clock drift silently corrupts timing, session judgement and timestamps
• Time-zone and daylight-saving handling is error-prone across libraries and machines
• A crash between scheduled jobs can leave state unreconciled until the next startup

Common mistakes

• Assuming every weekday is a trading day and skipping the holiday-calendar check
• Hardcoding session times in code instead of consulting a maintainable calendar
• Relying on an unsynchronised local clock for order timestamps and session decisions
• Skipping warm-up so indicators act on insufficient history at the open
• Killing the process abruptly instead of running a graceful shutdown that squares off and persists state
• Ignoring time zones or daylight-saving, silently shifting session boundaries

Professional usage

Professional systems drive timing from an explicit exchange calendar and session model rather than raw cron, so every job first asks whether it is a trading day and which session is active. Warm-up and shutdown are first-class, deterministic routines with self-checks, and the machine clock is NTP-synchronised with time zones handled explicitly. Scheduled jobs are idempotent and overlap-protected, and a crash is recovered by reconciling on the next startup rather than assuming a clean prior state.

Frequently asked questions

Voice search & related questions

Natural-language questions people ask about Scheduling.

Sources & references

Last reviewed 11 July 2026. Educational content only — not investment advice. Markets and rules change; verify current conventions with SEBI, NSE/BSE and your broker.