Best practices for dealing with API outage and high volatility events

pavinjoseph
Hello everyone ????

I was a sysadmin before I became a programmer so I tend to think about things such as how to handle outages, server updates, etc. a little more than others. Mitigating outage on my end is quite simple using staggered host updates after market hours and using multiple cloud providers & locations (DigitalOcean BLR and Linode CHE if anyone's wondering).

My main concerns are regarding broker API risk of outage which I cannot handle (or should I hedge using another broker, this would be complicated!)
I use the API to sell strangles on intraday timeframe, with the challenged side being squared off after hitting stoploss (SL) while tightening the SL on the now naked leg.
I'm thinking of doing this with some larger volume as a steady income source (favoring consistency over large profits), so need to have mitigation in place to protect capital at all costs, even if it is not an issue on my end.
As such, I would like to know the best practices for dealing with an API outage especially during high volatility / whipsaw events.

For example, is it better to use GTT SL and have my program monitor its execution rather than letting my program directly handle squaring off of positions? The GTT ToS does not give me much confidence as Zerodha absolves any responsibility for GTT not being triggered, and there are many users who attest to this during high volatility events.
Another option I've been thinking about would be to place hedge buy orders using a secondary broker and their API when there's a Zerodha / primary API outage essentially making the naked leg into a fully hedged spread position. I may break-even or even lose some money but it wouldn't be as catastrophic as without it.

Thank you and I look forward to your thoughts on the matter. ????
P.S. I could not find a status/incident page for Zerodha with historical uptime/incident display. Is this not available? ????
Sign In or Register to comment.