Hoe bouw je een 'Emergency Dashboard' om alle posities direct te sluiten?

Portret van Alex de Vries, Quantitatief Analist & Algo-Trading Expert
Alex de Vries
Quantitatief Analist & Algo-Trading Expert
Foutmeldingen & Debugging Live Bots · 2026-02-15 · 7 min leestijd

Een noodstop voor je bot is geen luxe; het is een must-have.

Stel je voor: een trade loopt compleet verkeerd, de markt crasht en je bot handelt vrolijk door. Je wilt één knop hebben die alles direct sluit, zonder dat je eerst drie schermen moet openen. In deze handleiding bouw je een Emergency Dashboard dat via je broker-API al je posities in één klap sluit. We houden het praktisch, met Python, en met concrete getallen zodat je meteen aan de slag kunt.

Wat je nodig hebt: materialen en voorwaarden

Je hebt een werkende Python-omgeving nodig, bijvoorbeeld Python 3.11 of nieuwer. Gebruik een virtuele omgeving (venv) om je dependencies netjes te houden.

Installeer de packages via: pip install flask ccxt pandas python-dotenv. Deze combinatie dekt je broker-verbinding (ccxt), een lichte web-interface (Flask) en data-opslag (pandas) voor de positie-overzichten.

Je broker moet API-toegang bieden. Populaire opties voor algoritmische trading zijn Interactive Brokers (TWS API), Binance (ccxt), Kraken, Bybit of Bitvavo. Voorbeeldkosten: Binance futures maker fee circa 0,02%, taker 0,04%; Kraken futures maker 0,02%, taker 0,05%.

Zorg dat je API-keys enkel trade-permissies hebben, nooit withdraw. Gebruik een apart subaccount voor bots, zodat je live- en testfunds scheidt. Voor risicomanagement zorg je voor een aparte “noodrekening” of subaccount. Handel met hefboom 1x of 5x max op je hoofdaccount, en test je noodknop op een paper-account.

Zorg dat je broker-rate limits kent (bijv. 1200 requests per minuut op Binance), want je dashboard moet onder druk niet vastlopen.

Tijdens build: reken op 2–4 uur voor een minimale versie, plus 1–2 uur testen.

Tip: bewaar je API-keys in een .env-bestand en commit die nooit. Gebruik een .gitignore.

Stap 1: API-toegang regelen en veilig opslaan

Maak een nieuw mapje aan, bijvoorbeeld emergency_dashboard. Daarin leg je een .env-bestand met:

  • BROKER=binance (of kraken, ibkr, etc.)
  • API_KEY=je_key
  • API_SECRET=je_secret
  • TESTNET=true (eerst testen!) of false voor live

Test je verbinding met een simpele ccxt-aanroep: print de balance van je account. Als je balance ziet, werkt de key.

Veelgemaakte fouten: per ongeluk live-keys in je repo zetten, of read/write-permissies geven terwijl je alleen trade-permissies nodig hebt. Ook: vergeten om IP-whitelisting in te stellen bij de broker, waardoor je verbinding wordt geblokkeerd. Tijdsindicatie: 15–30 minuten. Check dat je broker rate limits respecteert. Bij Binance bijvoorbeeld een limiet van 10 order calls per seconde voor futures.

Je dashboard moet die limieten kennen en eventueel een korte wachtrij (queue) gebruiken om te voorkomen dat je orders worden geweigerd.

Dit voorkomt een hoop frustratie tijdens een echte crash.

Stap 2: een minimale Flask-app opzetten

Maak een bestand app.py en start een simpele Flask-server. Gebruik een knop op de homepage die naar een route /panic stuurt.

Zet de app op localhost:5000 en zet later een licht beveiligde versie op een VPS (bijv.

DigitalOcean, €5–6 per maand). Gebruik een environment-variabele voor een wachtwoord, zodat je niet per ongeluk openbaar de noodknop activeert. Voeg een status-pagina toe die je posities live laat zien: symbool, grootte, entry, marktprijs, PnL, hefboom.

Gebruik pandas voor een nette tabelweergave. Voor een eerste versie is een simpele lijst voldoende; je hoeft geen fancy charts te bouwen.

Hou de code klein en begrijpelijk, zodat je snel kunt debuggen. Veelgemaakte fouten: Flask draait lokaal en je vergeet een wachtwoord of firewall. Gebruik een simpel .env-wachtwoord en zet de server achter een reverse proxy (nginx) met basic auth. Tijdsindicatie: 30–45 minuten. Zorg dat je een fallback hebt: als de webserver down is, kun je via een CLI-script alsnog sluiten.

Stap 3: posities uitlezen per account en symbool

Gebruik ccxt om open posities op te halen. Voorbeeld: voor Binance futures gebruik je fetch_positions([symbol]) of fetch_positions() voor alle symbolen. Sla de data op in een DataFrame met kolommen: symbol, side, size, entry, mark_price, leverage, notional, unrealized_pnl.

Toon dit op je dashboard, zodat je in één oogopslag ziet wat er speelt.

Als je meerdere brokers gebruikt (bijv. Kraken voor spot en Binance voor futures), bouw dan een adapter-laagje.

Schrijf een functie die voor elke broker een uniforme positie-structuur teruggeeft. Zo hoef je in de sluit-logica maar één format te hanteren. Hou rekening met verschillen: futures hebben een long/short-side, spot niet.

Veelgemaakte fouten: vergeten dat open_orders niet hetzelfde is als posities, of de verkeerde API-endpoint gebruiken.

Ook: hefboom per positie niet uitlezen, waardoor je risico onderschat. Tijdsindicatie: 45–60 minuten. Test met een paper-account en open een kleine long en short, zodat je zeker weet dat je beide kanten ziet.

Stap 4: de noodknop bouwen die direct sluit

Maak een route /panic die voor elke open positie een market-order aanmaakt om te sluiten. Voor een long sluit je met een verkooporder, voor een short met een kooporder.

Gebruik market-orders voor snelheid, maar pas op: bij lage liquiditeit betaal je wat spread.

Je kunt ook een limit-order op de huidige marktprijs plaatsen, met een kleine safety-buffer. Verdeel het sluiten over meerdere orders als je groot inzet. Bijvoorbeeld: als je 10 BTC long hebt op Binance futures, sluit dan in batches van 2 BTC, met 100 ms tussen de orders om rate limits te respecteren.

Geef je bot een timeouts-limiet (bijv. 5 seconden per broker) en log elke order met een timestamp. Zo houd je overzicht tijdens paniek. Veelgemaakte fouten: verkeerde side meegeven (long sluiten met een kooporder), of als je bot geen orders plaatst, check dan of je positie al deels is gesloten.

Ook: niet controleren of de order daadwerkelijk is uitgevoerd. Tijdsindicatie: 60–90 minuten.

Test op een paper-account met 10–20 posities tegelijk, zodat je de batching en rate limits valideert.

Stap 5: veiligheid, logging en herstel na fouten

Zet een simpel logbestand neer (bijv. panic.log) en schrijf per actie: timestamp, symbool, side, grootte, order_id, uitvoerstatus. Gebruik een lichtgewicht library zoals structlog of de standaard logging-module.

Als een order faalt, sla dan de foutmelding op en leer wat te doen bij een ghost trade, of probeer een tweede keer met een iets andere prijs (bijv. 0,1% verschuiving). Beveilig je dashboard met een wachtwoord via .env en een reverse proxy. Zet een IP-whitelist op de broker-API, en beperk je VPS tot enkel noodzakelijke poorten (bijv. 443).

Gebruik een tweede factor voor toegang tot de VPS (SSH-key + 2FA).

Zo voorkom je dat iemand per ongeluk of opzettelijk je noodknop activeert. Veelgemaakte fouten: geen fallback als de API down is, of vergeten dat je bot ook stoploss-orders heeft die nu botsen met je market-order. Tijdsindicatie: 30–45 minuten. Test een failure-scenario: trek de internetkabel eruit tijdens een sluitactie en leer hoe je de state van je bot herstelt als deze crasht, zodat je log genoeg info geeft om handmatig af te handelen.

Stap 6: testen, verbeteren en live zetten

Test eerst op paper-account: open 5–10 posities met verschillende symbolen en hefbomen, activeer de noodknop en controleer of alles binnen een paar seconden sluit. Gebruik een stopwatch: aim voor < 5 seconden voor 10 posities.

Pas batching aan als je rate limits raakt. Voeg een “nood-stop” toe voor specifieke symbolen als je niet alles wilt sluiten.

Gebruik een backtesting-omgeving om je sluitstrategie te valideren. Schrijf een Python-script dat historical data (bijv. 1 minuut-candles) gebruikt en simuleert wat er gebeurt als je market-orders uitvoert tijdens een dip.

Check slippage en kosten. Pas je script aan: bij extreme spread kun je beter in batches sluiten of een kleine limietbuffer gebruiken.

Veelgemaakte fouten: live gaan zonder load-test, of vergeten dat je dashboard ook moet werken als je broker tijdelijk onderhoud heeft. Tijdsindicatie: 60–90 minuten testen + 30 minuten live-check. Zet een monitoring-alert op je VPS (bijv. UptimeRobot) en een e-mailalert bij een mislukte sluitactie.

Verificatie-checklist

  • API-keys staan in .env en hebben alleen trade-permissies.
  • Paper-account gebruikt voor eerste tests; live-account met aparte subaccount.
  • Dashboard toont open posities met symbool, grootte, entry, marktprijs, PnL, hefboom.
  • Noodknop sluit longs en shorts correct via market-orders (of limiet met buffer).
  • Batching en rate limits zijn ingebouwd; geen 429-errors tijdens stress-test.
  • Logging is actief; elke order krijgt een ID en status opgeslagen.
  • Beveiliging: wachtwoord, IP-whitelist, reverse proxy met basic auth.
  • Herstelplan: fallback CLI-script en handmatige afhandeling bij API-fout.
  • Monitoring: uptime-alert en e-mail/SMS bij mislukte sluitactie.
  • Backtest-simulatie uitgevoerd; slippage en kosten gecheckt voor jouw broker.

Met deze checklist weet je zeker dat je Emergency Dashboard betrouwbaar is en dat je in een crisissituatie direct kunt ingrijpen.

Bouw het stap voor stap, test grondig, en hou het simpel. Een goede noodknop geeft je gemoedsrust, en dat is onbetaalbaar als de markt onverwachts beweegt.

Portret van Alex de Vries, Quantitatief Analist & Algo-Trading Expert
Over Alex de Vries

Alex is een ervaren quantitatief analist en Python-ontwikkelaar die complexe trading concepten vertaalt naar begrijpelijke, praktische handleidingen voor zowel beginners als gevorderden.

Volgende stap
Bekijk alle artikelen over Foutmeldingen & Debugging Live Bots
Ga naar overzicht →