Halt triggers are almost always round. Ten percent from the peak, five percent in a day, three losers in a row. Nobody derived those from the strategy they are attached to, and it shows in the two ways they fail. Set too tight, the switch fires on ordinary bad days, someone gets tired of restarting the profile, and within a quarter the control is either widened without analysis or quietly ignored. Set too loose, it never fires at all, which feels like success right up until the day it was supposed to work.
The alternative is not complicated. Build the loss distribution the profile actually produced in simulation, choose a percentile, and state in advance how many times a year that percentile should be breached. Then the switch has a specification, and when it fires you know whether it is behaving or misconfigured.
The switch on the page is a button, which changes the specification
Before deriving anything, look at what you are configuring. On the Autopilot page the emergency kill switch sits in the actions row alongside pause all, resume all and import. It is a control someone presses, and it operates at the fleet level rather than on a single profile.
Both of those facts matter more than the threshold arithmetic. A manual switch means the specification is not just a number, it is a number plus an observer plus a reachable person, and the weakest of the three sets your actual response time. And a fleet level control means a threshold derived from one profile's loss curve triggers an action that stops everything. On a desk running eleven profiles with ten enabled, which is what the header reported at the time of writing, that is a large asymmetry to leave undocumented: the profile that misbehaves halts the nine that were fine.
So write the design as three lines rather than one. The trigger, measured on what. The action, at what scope. And the person, with a route to reach them at the hours the profile trades. If per profile halting exists in the profile editor, prefer it for strategy specific triggers and reserve the global switch for infrastructure events, which are the ones where stopping everything is the correct response.
Building the loss curve the panel does not hand you
The Backtest a Profile panel takes a profile, a number of days and a start equity, and replays historical signals against the profile with no real orders, honoring the profile's filters, sizing, leverage caps and risk guards. That gives you a simulated record under your actual constraints, which is the right input. What I cannot confirm is that the panel presents a loss distribution or an equity curve as output, so plan to construct it from the run's trade list rather than expecting it on screen.
The construction is mechanical. Take the run's closed trades with timestamps and results, aggregate to daily net, and you have a series of daily outcomes under the profile's own rules. From that series you need three things: the empirical quantiles of the loss side, the distribution of peak to trough drawdowns, and the run of consecutive losing days.
Two decisions in that aggregation are worth making deliberately. Mark to market or realised: a profile holding positions across days has open risk that a realised only series will not show, and if your halt trigger is going to be evaluated intraday against a live book, the distribution it came from should be marked the same way. And the trading calendar: a 24 hour crypto profile produces roughly 365 observations a year while a session bound equity profile produces roughly 252, and the same percentile means a different firing frequency in each. The profile list on this desk spans both, with equity names on a daily cadence and crypto and metals pairs on a four hour cadence, so the calendar has to be chosen per profile rather than once.
Choosing the percentile, then stating the firing rate out loud
Pick the threshold as a quantile of the loss distribution, then immediately convert it into an expected number of firings per year. That second step is what makes the choice reviewable.
On a session bound profile with about 252 observations a year, a trigger at the 95th percentile of daily loss should fire around twelve or thirteen times a year, which is once a month, which is too often for a control that halts a fleet. The 99th percentile lands near two and a half times a year. The 99.5th is closer to once a year, and once a year is roughly the frequency at which a manual control still gets taken seriously when it fires. On a 24 hour profile the same percentiles yield about eighteen, three and a half, and two.
Say that number in the design document. It converts an unfalsifiable choice into a testable one, because you can now check it. If a 99th percentile trigger has fired five times in six months, the distribution you derived it from no longer describes the market you are in, and that is information about the strategy rather than a nuisance to be tuned away.
Do the same for drawdown. A peak to trough threshold should be set above the worst drawdown the simulation produced, not at it, because a strategy that never exceeds its historical worst case is a strategy you have not run for long enough. A common convention is to set the halt where the drawdown would be difficult to explain as ordinary given the sample, and to write down the sample size that supports the claim. With one hundred and eighty days of history, honest language is that the estimate is weak in the tail and the threshold is provisional pending more observations.
Two thresholds, because a halt is the wrong response to most bad days
A single trigger forces every degree of trouble into the same action. Split it.
The lower one, somewhere around the 95th percentile, is a review trigger. It does not stop anything. It generates a notification, and it obliges someone to look at the profile within a defined window and record what they found. Most breaches will resolve as ordinary variance, and the value is that you accumulate a written history of bad days, which is the sample you will need the next time someone proposes changing the threshold.
The upper one is the halt, and it should be reserved for the region where the loss is hard to reconcile with the simulated distribution at all. Between them, define what happens to open positions on a halt. Stopping new entries and leaving positions open is a different risk posture from flattening the book, and a control whose behaviour on that point is unknown is not a control. Test it on a live profile with a small position open, once, and write down what happened.
The losses the distribution never saw
The whole method rests on an assumption worth stating plainly, which is that the simulated loss distribution resembles the live one. The module's own warning on this page argues against complacency there: with paper mode off, Autopilot places real orders on connected exchanges, execution prices may differ from signal prices because of market conditions and latency, and the user is solely responsible for the trades. The prescribed sequence is paper first, verify behaviour, then live at small size.
Three categories of loss are systematically absent from a replay. Gaps, where the market reopens through your stop and the realised loss is unrelated to the level you configured. Execution failure, where orders reject, fill partially, or fill late enough that the trade is a different trade. And correlated fleet behaviour, where several profiles built on the same signal source lose together, so the desk level number breaches long before any single profile's threshold does. That last one is the argument for computing at least one threshold on aggregate exposure rather than per profile, since the fleet is what the emergency switch actually controls.
The failure mode to design against is not the switch firing late. It is the switch firing correctly at three in the morning with nobody watching the screen it fires on. A threshold derived from a loss curve is a genuine improvement over a round number, and it is worth precisely as much as your coverage at the hour the profile trades.