When a Zerodha-Linked Algo Session Dies Mid-Day: Orphan Legs, Expired Tokens and a Manual Fallback P
Picture a Thursday expiry. You sold a straddle at 09:20 and bought two far wings as protection. Everything looks calm. At 12:40 the market starts to move, your algo tries to square off the short call, and nothing happens. The order is rejected. The screen says the session is invalid.This is not a rare freak event. Anyone who connects software to a broker will meet some version of it. A login expires, a token goes stale, a connection drops, or the broker throttles requests during a busy minute. The software cannot place orders until the link is restored, and the positions you already hold keep moving whether the link is up or not.
This article is about that gap. It explains how broker sessions work in plain terms, what can go wrong with multi-leg option positions when one dies, how orphan legs form, and how to write a manual fallback plan that you can follow when you are stressed. It makes no claims about how any one product behaves. Mechanics differ between brokers and tools, so wherever it matters, check the current documentation of your own setup.
How a Broker Session Actually Works
When you log in to a broker app, you prove who you are once and receive a short-lived pass. That pass is what the app uses for every request after that. If you connect third-party software, the software usually holds a similar pass, often called an access token or a session token. It is not your password. It is a temporary key that says, "this program is allowed to act for this account until time T".
Three facts about these passes explain most mid-day failures.
First, they expire. Many retail broker connections issue passes that last one trading day, or until a set time in the morning, after which a fresh login is needed. Some last longer, some shorter, and the rules differ by broker. Never assume. Read what your broker says and write the expiry time on your checklist.
Second, they can be cancelled early. If you log in on another device, change a password, or the broker resets sessions for security, your earlier pass may stop working at once. The software then gets errors it did not expect.
Third, the pass lives in two places that can disagree: the broker's server and your software. The broker may consider the session dead while your software still believes it is alive, and keeps sending orders that bounce. The reverse can happen too.
The daily re-login is a feature, not a bug
Fresh logins each day exist for security. They limit the damage if a key leaks and they make the regulator's expectations around authentication easier to meet. SEBI has been tightening the rules for retail algo access, and you can follow the regulator's circulars on the SEBI website. The practical point is that the daily login step is likely to stay. Your process has to treat it as a normal part of the day, not a nuisance to be worked around.
The Four Ways a Session Can Fail
Not every failure looks the same, and the fix depends on which one you have. Learn to tell them apart.
The first two give you clear errors. The third and fourth often give you silence, which is worse. If your software does not shout when orders fail, you may not know for minutes. That delay is where the money goes.
What Happens to Open Multi-Leg Positions
Here is the key point for option sellers. When your session dies, your positions do not pause. They stay open at the exchange, they keep their margin, and their value keeps changing with every tick. The only thing that stops is your ability to change them through that link.
Whether anything else happens depends on settings you chose earlier. Stop-loss orders that were placed at the broker as live orders, and not held inside your software, will generally still be there and can still trigger. Stop-losses that exist only as a rule inside your software will not fire, because the software has no permission to send the exit. This single difference decides how bad a mid-day failure is.
That leads to a question every algo user should answer in writing: where does each protective order live? If the answer is "inside the software", then a session failure means the position is unprotected from that minute until you restore the link or act by hand.
1. Live stop order sitting at the broker or exchange
- If the session dies: Still active and can fill.
- Risk: Lower, but you cannot modify or cancel it.
2. Software-held stop (monitors price, then sends an order)
- If the session dies: Does nothing.
- Risk: High; position is naked of rules.
3. Hedge legs (bought wings) already held
- If the session dies: Stay in place.
- Risk: Lower; they cap the worst case.
4. Time-based exit (e.g. exit at 15:15) in software
- If the session dies: Does not run.
- Risk: Moderate; you must exit by hand before close.
Please check the actual behaviour of your own tool. Some platforms place exchange-side orders at entry, some hold them locally, and some do a mix that depends on the order type. The only reliable answer is in the vendor's current documentation, or from a small test in a quiet moment with the smallest possible size.
How Orphan Legs Form
An orphan leg is one leg of a multi-leg position that is left open while its partners are closed, or never opened. It is the most dangerous outcome of a mid-day failure, because it changes the shape of your risk without any warning.
There are three common routes to an orphan.
Half-filled entries
Suppose your strategy sells a call, sells a put and buys two wings, all sent as four orders. The session dies after two of the four are filled. If the filled two happen to be the short legs, you now hold a naked straddle with no wings, and the margin and risk are very different from what you planned. If the filled two are the wings, you hold two long options that will decay, and no short premium to offset them.
Good tools send protective legs (the bought wings) first, so that a failure leaves you with less risk and not more. But not every setup does this, and a tool that sends orders in parallel offers no guarantee about which fills first. This is worth asking about before you go live.
Half-completed exits
The mirror case happens at exit. Your rule fires and begins to close the position. The short call is bought back. Then the session dies before the short put is closed. Now you hold a naked short put, plus whatever wings remain, and the market is moving. The wings that were meant to protect the call side may still be open and will decay, and the put side is exposed.
Rejected adjustments
Many strategies adjust mid-day. They shift a leg, add a hedge, or roll a side. If the session fails halfway through an adjustment, the book can end up with an extra leg, a missing leg or the wrong quantity. These are the hardest to spot, because the position looks plausible at a glance.
In all three cases the basic fix is the same. Compare what you hold with what you meant to hold, leg by leg, as soon as the link returns. Do not trust the software's picture until you have checked it against the broker's own position list.
Where Do Third-Party Tools Fit In?
Many retail traders do not write their own software. They use a platform that connects to a broker and runs the strategy. That adds one more link in the chain, and one more place the session can fail: the platform's own login, plus the broker's.
If you are wiring a third-party platform to a broker, the step-by-step guide on AlgoTest and Zerodha is a useful reference for what the connect-and-login flow involves in practice. What it cannot tell you, and no setup guide can, is what your own positions will do at 13:40 on the day the pass runs out. That depends on your order types, your sizing and your plan, and the rest of this article is about building that plan.
Whatever tool you use, there are two sessions to watch: the one between you and the platform, and the one between the platform and the broker. A failure in either gives you the same symptom, which is orders that do not go through. Know which one to check first. Usually the answer is the broker, because it is the one that holds your positions.
The Hour That Matters: Timing a Failure
When the session dies matters a great deal. A failure at 09:10, before you have any position, costs you a missed trade. A failure at 10:30, when you hold a fresh short straddle, is a risk event. A failure at 14:50 on an expiry day is the worst case, because the last hour is when moves are largest relative to the premium left and when exits are most urgent.
EliteAlgo's desk study of 163 NIFTY and SENSEX weekly expiry sessions between January 2025 and July 2026 gives a sense of what is at stake in the middle of the day. For a short ATM straddle entered at 09:20, 86 of 159 usable days gave back more than 30% of the intraday peak profit, and on 48 of the 159 days, a trade that had been in profit at some point finished the day at a loss. The median give-back was 42.8% of the peak. These are descriptions of one entry rule in one period and not a forecast, but they show how much a position can change after the first few hours. If you are blind for an hour in the middle of that, you may miss both the peak and the chance to exit before the give-back.
It also helps to know that the premium curve itself is not smooth. In the same study the average straddle premium fell to about 88.6% of its entry level by 11:16 and then stayed in a band of roughly 88% to 93% for the rest of the afternoon. Time decay alone does not pull a short position to safety. Spot keeps moving, and gamma risk is still there. A dead session at 13:30 is not a quiet period you can sit through safely.
Build Your Manual Fallback Plan Before You Need It
The fallback plan is a one-page document. It should be short enough to follow under stress, and specific enough that there are no decisions left in it. Write it when you are calm, print it or keep it open on a second device, and rehearse it once.
Part one: the information you need in seconds
List the following in one place: your broker's app and web login, the phone number of the dealing desk or support line for placing orders by phone (verify it on the broker's official site, not from memory), the second device or network you can use, and the legs of each strategy with quantities. Having the strategy structure written down lets you compare it with what the broker shows.
Part two: the decision tree
- Confirm the failure type. Is it auth errors, no data, or the broker being down for everyone?
- Open the broker's own app or web terminal, which uses a separate login from the software. Check the live position list and the open orders list.
- Compare with your plan, leg by leg. Note any orphan.
- If an orphan short leg exists, decide at once: close it, or restore the hedge. Do not leave it while you debug the software.
- Only after the positions are in a known, acceptable state, return to fixing the link.
The order of those steps matters. Traders lose time trying to repair the software first, with the market moving, while a naked leg sits open. Position safety comes first, software second.
Part three: pre-agreed rules for the manual mode
Decide in advance what you do if the link cannot be restored in, say, ten minutes. A clean answer is to flatten everything manually, starting with the shorts, or buy back the short legs first and let the long wings expire. Whatever you choose, write it down as a rule so that you are not inventing it at the worst moment.
For multi-leg positions, the standard principle is to remove the unlimited-risk leg first. If you hold a short strangle with no wings and must exit by hand, buy back the leg that is going against you before the other, or both quickly, and do not worry about getting the tidiest price. The aim is to cap the loss, not to win the exit.
Reducing the Odds of a Mid-Day Failure and Learning From One
You cannot remove the risk, but you can shrink it with small habits.
1. Log in and refresh the token well before the open
- Gives time to fix a bad login before orders are due.
2. Run a tiny test order or a status check at 09:00
- Proves the link works end to end, not just that the screen looks fine.
3. Send hedge legs first and confirm fills before the shorts
- A failure then leaves less risk, not more.
4. Prefer broker-side protective orders where your setup allows
- They survive a software or session failure.
5. Do not log in on a second device during the session
- May cancel the first session.
6. Use a stable internet line and a backup, such as a phone hotspot
- Removes the most common non-broker cause.
7. Set up alerts for rejected orders and for missing data
- Turns silent failures into loud ones.
8. Keep a second login, such as the broker's mobile app, ready
- Gives you a manual route in seconds.
Monitor the link, not only the market
Most traders watch prices. Few watch the health of the connection. A simple heartbeat check helps: every minute, ask the broker for something harmless, such as the funds balance or the order book, and raise an alert if the request fails twice in a row. A failed heartbeat tells you the link is broken before you need to place an order. It costs almost nothing and removes the worst surprise: finding out at the moment of need.
Avoid the retry storm
Some tools retry failed orders again and again. If the failure is a throttle, hundreds of retries make it worse and may get your access limited. If the failure is auth, retries never succeed. Set a sensible cap on retries, and make the tool stop and alert you after that, rather than keep hammering.
After the failure: reconcile and learn
Once the day is over, go through the incident in writing. Record when the failure began, how you found out, what the positions looked like, what you did, and what it cost. Compare the software's final position with the broker's contract note for the day, leg by leg, to make sure nothing stayed open or was doubled.
Look for patterns. If failures cluster in the first minute after the open, perhaps the token refresh is late. If they cluster at the same time every week, perhaps another login is cancelling the first. If they follow a software update, roll it back or test updates on a quiet day.
Also check the margin side. A leg left open overnight by mistake, or a doubled position, can change margin use sharply. Review your margin statement on the next morning, and confirm that the account is in the state you expect before the next session.
Regulation and the shared responsibility for access
Brokers are under growing pressure to control how third-party software reaches client accounts. That means more authentication steps, tighter limits on who can connect, and in some cases more frequent re-logins. Expect your setup to change over time. Review your broker's circulars and the exchanges' notices, such as those on the NSE website, and re-test your fallback plan whenever the access rules change.
Frequently Asked Questions
What happens to my open option positions if my algo loses connection to the broker?
The positions stay open at the exchange and keep moving with the market. Only your ability to change them through that link stops. Stop-loss orders already live at the broker may still trigger. Rules held only inside your software will not run.
Why do I have to log in to my broker every day for algo trading?
Broker connections use short-lived tokens for security. Many expire daily, so a fresh login is needed. The exact timing differs by broker, so check your broker's documentation and plan the login before market open.
What is an orphan leg in a multi-leg option strategy?
It is a leg left open when its partner legs are closed or were never filled. A common example is a short option without its protective wing. It changes your risk without any warning, so compare the broker's position list with your plan whenever the link has been interrupted.
Can I close positions manually if my algo software stops working?
Yes. Log in to the broker's own app or web terminal, check the positions and open orders, and exit by hand. Many brokers also accept orders by phone through a dealing desk. Keep the details in your fallback plan, and verify them on the broker's official site.
Should I use broker-side stop-losses instead of software stop-losses?
Broker-side orders can survive a software or session failure, which is a real advantage. They can also behave differently on fills and modification. Whether your tool supports them depends on its design, so read its current documentation and test with minimum size.
How do I know my algo has stopped placing orders?
Do not rely on a quiet screen. Set alerts for rejected orders and failed heartbeat checks, and look at the broker's order book now and then. Silence can mean everything is fine or that nothing is working.
Conclusion
A broker session is a temporary permission, and it can end at the worst time. When it does, your positions carry on, protection that lives only in software stops, and half-finished entries or exits turn into orphan legs. The damage depends less on the failure itself than on what you decided beforehand.
Know where every protective order lives. Send hedges first. Watch the health of the link. Keep a one-page manual plan with the broker's own app, a phone route and a rule for what to flatten first. Rehearse it once in calm conditions. Then a dead session becomes an irritating event with a script, not a crisis.
Risk note: algo trading and options selling carry a real risk of loss, including loss greater than your initial margin, and technology failures can add to it. EliteAlgo is analytical software and not an investment adviser. Nothing in this article is investment advice, a recommendation or a trade call, and the examples are illustrative only.