DEV Community: matteo adorni

Keep Freqtrade running 24/7: systemd vs a zero-dependency watchdog

matteo adorni — Fri, 25 Sep 2026 15:22:31 +0000

You built the strategy. You backtested it. You started it with nohup. Three days later you check the P&L and… the process is gone. It has been gone since roughly two hours after you closed the terminal.

"Keep Freqtrade running" is the number one operational question in every Freqtrade forum, and the answers split into two camps: systemd and a cron watchdog. I have run both in production-style setups. Here is the honest comparison, and the pattern I actually use.

Option 1: systemd (the "proper" way)

# /etc/systemd/system/freqtrade.service
[Unit]
Description=Freqtrade
After=network.target

[Service]
User=freqtrade
WorkingDirectory=/home/freqtrade
ExecStart=/home/freqtrade/.venv/bin/freqtrade trade --config user_data/config.json
Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

sudo systemctl enable --now freqtrade

What you get: automatic restart on crash, restart on reboot, journalctl logs, clean systemctl stop.

The catches, in practice:

It only restarts the process. It does not check that the thing is healthy. A Freqtrade process can be alive and stuck: exchange connection dropped, a hung API, a wedged websocket. Restart=always sees a running PID and does nothing.
No P&L record. You find out about a silent stall by noticing the trade count never moved.
No risk rule. If your bot is bleeding, systemd faithfully keeps it bleeding.
It needs root to install, and sudo on a cheap VPS is a thing you have to think about.

systemd is excellent at "make sure a binary is running". It is not an observability or risk layer, and it never claimed to be.

Option 2: cron + watchdog (the pattern I use)

A tiny script, run every 15 minutes, that does three jobs: restart if dead, record health, and enforce a kill switch.

*/15 * * * * /home/user/freqtrade/scripts/crypto_watchdog.sh

The restart detection is the part that matters, and the naive version is a trap:

# DO NOT DO THIS
if ! pgrep -f freqtrade > /dev/null; then restart; fi

pgrep -f matches the full command line, and your watchdog's own invocation may contain the pattern — so the script can match itself, conclude "all good", or pkill its own shell. I hit exactly this and wasted an hour on a watchdog that was killing itself.

Do it properly by scanning /proc and requiring two independent facts:

VENV_PY=$(readlink -f "$BASE/.venv/bin/python")

find_bot() {
  for p in /proc/[0-9]*; do
    pid=${p#/proc/}
    [ -r "$p/cmdline" ] || continue
    cmd=$(tr '\0' ' ' < "$p/cmdline" 2>/dev/null) || continue
    case "$cmd" in
      *"freqtrade trade --config"*)
        exe=$(readlink -f "$p/exe" 2>/dev/null)
        [ "$exe" = "$VENV_PY" ] && echo "$pid"
        ;;
    esac
  done
}

/proc/<pid>/cmdline is the real argv (NUL-separated), not a shell's mangled string.
/proc/<pid>/exe must resolve to your venv interpreter — so you can never match a stray system Python or the watchdog itself.

Then the loop adds the two things systemd does not:

if [ -z "$(find_bot)" ]; then
  nohup "$BASE/.venv/bin/freqtrade" trade --config "$BASE/config.json" \
      --strategy SwingHighToSky --dry-run >> "$BASE/logs/trade_stdout.log" 2>&1 &
  sleep 30
  [ -n "$(find_bot)" ] || { echo "$(ts) restart FAILED"; exit 1; }
  echo "crypto-bot: restarted at $(ts)"   # speaks only when it acts
fi

OUT=$("$PY" "$BASE/monitor_pnl.py" 2>&1); RC=$?
if [ $RC -eq 2 ]; then                       # health script says: drawdown >= 10%
  for pid in $(find_bot); do kill "$pid"; done
  echo "$(ts) DRAWDOWN LIMIT HIT -> bot stopped"
  exit 2
fi
echo "$OUT" >> "$LOG"                        # one P&L line every 15 minutes

monitor_pnl.py polls the local Freqtrade REST API (/api/v1/profit, /api/v1/status, /api/v1/balance) and appends a single line:

2026-09-25T15:02:58Z wallet=500.13 closed_pnl=+0.000USDT (+0.00%) all_pnl=-0.000USDT trades=0W/0L wr=0.0% open=1

Now you have a time series, not a vibe. You can see the day the behaviour changed.

The comparison, honestly

	systemd	cron + watchdog
restart on crash	✅	✅
restart on reboot	✅ (`enable`)	✅ (cron is persistent)
needs root	✅	❌
detects "alive but stuck"	❌	✅ (health script)
P&L time series	❌	✅
enforced risk rule	❌	✅
moves to any machine in 2 files	❌	✅

Neither is "better". systemd is the right tool if all you need is "keep the binary up" and you have root. The watchdog wins when you want evidence and a kill switch — which, for anything handling money, is the actual requirement.

You can also run both: systemd to survive reboots, the watchdog cron for health and risk. They do not conflict.

What actually kills unattended bots

Ranked by how often I have seen them:

The process dies and nobody notices — the watchdog fixes this in the first five minutes.
It runs for weeks and you never look at the data — the P&L log fixes this.
It draws down and you are asleep — the kill switch fixes this.
Machine reboots and nothing restarts it — cron/enable fixes this.

Notice that three of the four are observability and risk, not supervision.

I packaged this exact layer — the /proc-based watchdog, the P&L logger and the drawdown kill switch, with a dry-run config and setup guide — as the Freqtrade Self-Healing Starter Kit ($9). It is the code from this post, ready to drop in, so you skip the hour I lost on the self-killing watchdog.

Related: Keep any long-running Python process alive on Linux for $0 (the /proc watchdog pattern) — the same pattern, generalised beyond Freqtrade.

Related in this series:

The watchdog from this post is open source: **https://github.com/moon-hacks/proc-watchdog* (MIT).*

Prefer someone to just do it? I also offer a **done-for-you setup* (https://tntofficial.gumroad.com/l/vweza) — Freqtrade installed, backtested and left running in dry-run with the watchdog active.*

I backtested 14 trading strategies. Only one passed my filters.

matteo adorni — Fri, 25 Sep 2026 15:20:14 +0000

The first time I backtested a trading strategy, it returned a 100% win rate. Six trades. I almost shipped it.

That number told me nothing, and neither does the number you get from any single backtest run. What matters is a filter — a small set of criteria that data has to pass before you are allowed to believe it. This post is the filter, applied to 14 real Freqtrade strategies over a 200-day window with exchange fees included.

The setup (so you can reproduce it)

Data: 200 days of OHLCV for BTC/USDT, ETH/USDT, SOL/USDT.
Fees: 0.1% worst-case, included in every result below.
Window: 2026-03-10 → 2026-09-25, during which the market rose roughly +31%.
Engine: freqtrade backtesting --timerange 20260310-20260925 --breakdown.

freqtrade download-data --config config.json --days 200 --timeframes 5m 15m 1h
for s in $(ls user_data/strategies/*.py | xargs -n1 basename | sed 's/.py//'); do
  freqtrade backtesting --config config.json --strategy "$s" \
    --timerange 20260310-20260925 --breakdown > "logs/backtest_${s}.txt"
done

The filter

Three rules. Every one exists because of a specific way a backtest lies.

Profit factor > 1.5. Profit factor is gross profit ÷ gross loss. Below 1.5, a handful of lucky trades is doing all the work.
Max drawdown < 15%. A strategy you cannot psychologically survive is a strategy you will disable at the worst moment.
Win rate > 55% on a usable sample. 100% on six trades is noise. I only count a strategy as a candidate above ~50 trades.

And one meta-rule: compare against buy-and-hold. In a market that rose 31%, a strategy returning +1.6% did not beat the market. It just lost less badly than a coin flip. That does not make it worthless — it makes it honest, and honesty is what you want in the thing that decides your entries.

The results

strategy	tf	trades	win%	profit	profit factor	max drawdown	Sharpe
SwingHighToSky	15m	108	68.5%	+1.60%	5.21	0.37%	3.27
BbandRsi	1h	62	74.2%	+3.99%	1.38	7.92%	0.62
UniversalMACD	5m	6	100%	+1.48%	∞	0.00%	0.79
CombinedBinHAndCluc	5m	9	100%	+1.41%	∞	0.00%	1.25
ClucMay72018	5m	7	85.7%	+0.51%	6.52	0.09%	0.73

Read it the way the filter demands:

UniversalMACD and CombinedBinHAndCluc are traps. Perfect win rates, infinite profit factor — on 6 and 9 trades. An infinite profit factor means zero losing trades happened, which on a tiny sample is a coincidence, not an edge.
BbandRsi earns the most in absolute terms (+3.99%) but its profit factor of 1.38 fails rule 1. Big return, fragile distribution.
SwingHighToSky is the only one passing all three rules with a sample worth trusting: 108 trades, 68.5% win rate, profit factor 5.21, drawdown 0.37%.

One strategy out of fourteen. That ratio is the point — not that there is a winner, but that the filter is strict enough to make the winner meaningful.

Why the Sharpe column matters more than profit

Profit tells you what happened. Sharpe tells you how rough the ride was. SwingHighToSky returns less in absolute terms than BbandRsi but with a Sharpe of 3.27 vs 0.62 — a far smoother equity curve. For a bot you intend to leave running unattended, smoothness is not a luxury; it is what stops you from turning it off.

What I did with this

I did not pick the highest number. I picked the one that survived the filter, put it in dry-run, and left it running — because the next question is not "which strategy wins" but "can I keep it running, trusted, for two weeks". That is an infrastructure problem, not a strategy problem, and it is the part most backtests never reach:

the process has to come back if it dies,
the P&L has to be recorded so you can compare weeks,
a risk rule has to be enforced by code, not by willpower.

I packaged exactly that layer — a self-healing watchdog, a P&L logger, and a hard drawdown kill switch — into a small kit so you can put the filter's winner into a survivable setup in about five minutes.

→ Freqtrade Self-Healing Starter Kit ($9): the exact watchdog and config from this workflow, plus the setup guide.

The takeaway

Your backtest is a hypothesis generator, not an answer. Write the filter before you look at the results — otherwise you will rationalise the number you like. And always ask what the market did over the same window; a strategy that loses to buy-and-hold in a bull market still might be worth running, but only if you know that is what you are choosing.

This is part of a short series on running a trading bot you can actually leave alone.
The infrastructure layer (watchdog + P&L logger + drawdown kill switch) is packaged here:
Freqtrade Self-Healing Starter Kit — $9.

Related in this series:

The watchdog from this post is open source: **https://github.com/moon-hacks/proc-watchdog* (MIT).*

Keep any long-running Python process alive on Linux for $0 (the /proc watchdog pattern)

matteo adorni — Fri, 25 Sep 2026 15:01:43 +0000

Anything you leave running will eventually stop running. A scraper, a trading bot, an agent, a queue worker — it does not matter how good the code is. What matters is whether you find out in five minutes or in three weeks.

This is the pattern I use to make long-running processes self-healing, with no orchestrator, no systemd gymnastics, and no paid monitoring. It is a single bash script and a cron line. It works for anything: it does not need to know what your process does, only what it looks like.

The trap everyone falls into first

The obvious watchdog is this:

if ! pgrep -f "mybot" > /dev/null; then
  restart_mybot
fi

It looks correct. It is a landmine.

The problem: pgrep -f matches against the full command line, and your watchdog's own command line contains the pattern you are searching for. Depending on how the script is invoked (especially from cron or from a parent that echoes the command), the script can match itself and conclude the process is alive — or worse, pkill -f mybot will kill the shell that is running the watchdog.

I hit this exact bug: the watchdog ran, matched its own invocation, and killed itself before doing anything. The log looked like the bot was fine. It was not.

There is a second, subtler failure: matching a name is not matching a process. Any unrelated binary with the same substring satisfies the check.

The robust check: scan `/proc`, and require two things

Instead of matching a string, walk /proc and require both:

the command line contains your exact start command, and
the process's resolved executable is the one from your virtualenv.

VENV_PY=$(readlink -f "$BASE/.venv/bin/python")

find_bot() {
  for p in /proc/[0-9]*; do
    pid=${p#/proc/}
    [ -r "$p/cmdline" ] || continue
    cmd=$(tr '\0' ' ' < "$p/cmdline" 2>/dev/null) || continue
    case "$cmd" in
      *"freqtrade trade --config"*)
        exe=$(readlink -f "$p/exe" 2>/dev/null)
        [ "$exe" = "$VENV_PY" ] && echo "$pid"
        ;;
    esac
  done
}

Why this is safe:

/proc/<pid>/cmdline is the process's actual argv, NUL-separated — not a shell's mangled string.
readlink /proc/<pid>/exe resolves to the real binary. Requiring it to equal your venv's interpreter means you can never match a stray system Python, a shell, or the watchdog itself.
A process that has already died leaves no /proc/<pid> entry, so there is no stale-match window.

Adapt the case pattern and the exe path and this same function works for a Node app, a Go binary, a scraper — anything.

The full watchdog

This is production-shaped: it restarts the process, records a health snapshot on every run, enforces a safety rule, and stays silent unless it acts.

#!/bin/bash
# Generic self-healing watchdog. Silent on success.
set -u
BASE=/home/kali/myapp
VENV_PY=$(readlink -f "$BASE/.venv/bin/python")
cd "$BASE" || { echo "watchdog: cannot cd $BASE"; exit 1; }
LOG=$BASE/logs/watchdog.log
ts() { date -u +"%Y-%m-%dT%H:%M:%SZ"; }

find_proc() {
  for p in /proc/[0-9]*; do
    pid=${p#/proc/}
    [ -r "$p/cmdline" ] || continue
    cmd=$(tr '\0' ' ' < "$p/cmdline" 2>/dev/null) || continue
    case "$cmd" in
      *"myapp run --config"*)
        exe=$(readlink -f "$p/exe" 2>/dev/null)
        [ "$exe" = "$VENV_PY" ] && echo "$pid"
        ;;
    esac
  done
}

MSG=""
if [ -z "$(find_proc)" ]; then
  echo "$(ts) process not running -> restarting" >> "$LOG"
  nohup "$BASE/.venv/bin/python" -m myapp run --config "$BASE/config.json" \
      >> "$BASE/logs/app_stdout.log" 2>&1 &
  sleep 30                     # give it time to come up
  if [ -n "$(find_proc)" ]; then
    MSG="watchdog: restarted at $(ts)"
  else
    echo "$(ts) restart FAILED" >> "$LOG"
    exit 1                     # exit non-zero so cron mails / your notifier fires
  fi
fi

# health snapshot + safety rule (exit codes: 0 ok, 2 breach, 3 unreachable)
OUT=$("$VENV_PY" "$BASE/health.py" 2>&1); RC=$?
if [ $RC -eq 2 ]; then
  for pid in $(find_proc); do kill "$pid" 2>/dev/null; done
  echo "$(ts) SAFETY RULE TRIPPED -> stopping process" >> "$LOG"
  exit 2
fi
echo "$OUT" >> "$LOG"
[ -n "$MSG" ] && echo "$MSG"       # speak only when something happened
exit 0

Why "silent on success" is the important part

A watchdog that messages you every fifteen minutes gets muted within a day — and a muted watchdog is worse than none. Emit output only when you restarted something or a rule tripped, and pipe that output to whatever notifier you already use (a Discord webhook, mail, a Telegram bot). Silence means health.

The safety rule lives outside your app

Whatever invariant protects you from disaster — a loss limit for a trading bot, an error-rate ceiling for a scraper, a queue-depth threshold — put it in the watchdog's health script, in one place. Your app's internal guards protect a request; this protects the account. One threshold, one exit code, one kill switch.

Scheduling

*/15 * * * * /home/kali/myapp/scripts/watchdog.sh

Fifteen minutes is a good default: fast enough to matter, slow enough to be invisible. Make the script idempotent — two runs must not start two copies. The two-condition check above guarantees that: if the process exists, the function returns a PID and nothing is started.

Test it, or you do not have one

A watchdog you have never seen fire is a watchdog you do not have. Do this once, immediately:

# 1. kill the app
for pid in $(pgrep -f "myapp run --config"); do kill "$pid"; done
# 2. run the watchdog by hand
bash scripts/watchdog.sh
# 3. confirm BOTH the restart and the log line
tail -3 logs/watchdog.log

If it does not restart, you have a path or an exe mismatch — fix it now, not at 03:00.

The cost

Zero. A cron line, a bash script, and the filesystem you already have. No agent to install, no dashboard, no token, no monthly fee. For the 95% of solo projects that just need "it keeps running and tells me when it doesn't", this pattern beats a full orchestrator on every axis that matters: it is 60 lines you can read and reason about completely.

The two ideas worth keeping, whatever you build: identify processes by /proc + exe, never by name, and let the watchdog speak only when it acts.

Want this pre-built? I packaged the watchdog, the P&L logger, the backtest runner and the config
into a drop-in kit — Freqtrade Self-Healing Starter Kit ($9).
It is the exact code from this article plus a setup guide with the /proc gotcha already solved,
so you can go from zero to a self-healing bot in about five minutes.

Related in this series:

The watchdog from this post is open source: **https://github.com/moon-hacks/proc-watchdog* (MIT).*

Run a self-healing crypto trading bot 24/7 for $0 (Freqtrade + watchdog)

matteo adorni — Fri, 25 Sep 2026 14:35:55 +0000

Most "run a trading bot" tutorials stop at backtest passed, bot started. That is the easy 20%. The hard 80% is what happens on day 4 at 03:00 when the process is gone and you only notice three weeks later — with a flat equity curve and a dead clock.

This post is the part nobody writes: a production-shaped, zero-cost setup where the bot restarts itself, logs its own P&L, and hard-stops on a risk rule you define. Everything below was built and verified in a single afternoon on a $0 budget, using only open-source tooling. The dry-run trades are simulated — no exchange key, no real money, no risk.

Why a watchdog matters more than the strategy

A strategy is a hypothesis. A watchdog is what turns a hypothesis into data.

If your bot silently dies, every metric you were collecting stops: win rate, drawdown, profit factor. You think you are "running a 14-day validation" while in reality the last trade was nine days ago. A watchdog fixes three things cheaply:

Availability — the process is restarted automatically.
Observability — a P&L snapshot is appended to a log on every cycle, so you have a time series instead of a vibe.
Risk — a global rule (e.g. stop if drawdown ≥ 10% of the wallet) is enforced by code, not by willpower.

Prerequisites

Linux (or WSL2) with ~3 GB RAM.
uv for the Python environment. On modern distros pip install into the system Python is blocked by PEP 668, and uv sidesteps that cleanly.

curl -LsSf https://astral.sh/uv/install.sh | sh
uv venv ~/freqtrade/.venv
source ~/freqtrade/.venv/bin/activate
uv pip install freqtrade

A minimal, sane config

Start with a cosmetic config and tune later. The important bits for a safe dry-run:

{
  "max_open_trades": 3,
  "stake_currency": "USDT",
  "stake_amount": 50,
  "dry_run": true,
  "dry_run_wallet": 500,
  "trading_mode": "spot",
  "exchange": {
    "name": "binance",
    "key": "",
    "secret": "",
    "pair_whitelist": ["BTC/USDT", "ETH/USDT", "SOL/USDT"]
  },
  "pairlists": [{ "method": "StaticPairList" }],
  "api_server": {
    "enabled": true,
    "listen_ip_address": "127.0.0.1",
    "listen_port": 8080,
    "username": "hermes",
    "password": "CHANGE_ME",
    "jwt_secret_key": "CHANGE_ME_TOO",
    "ws_token": "CHANGE_ME_AS_WELL"
  },
  "bot_name": "dryrun",
  "initial_state": "running"
}

Two rules that will save you hours:

Bind the API to 127.0.0.1, never 0.0.0.0. The API exposes order and config operations.
Set jwt_secret_key, ws_token and a real password even in dry-run. Empty secrets are a production foot-gun waiting to be copied into live.

Backtest before you believe anything

Download history and backtest several strategies in their native timeframe. A common mistake is backtesting a 5-minute scalp strategy on 1-hour candles and concluding it is bad — you are measuring the timeframe, not the strategy.

freqtrade download-data --config config.json --days 200 --timeframes 5m 15m 1h

for s in SwingHighToSky BbandRsi UniversalMACD; do
  freqtrade backtesting --config config.json --strategy "$s" \
    --timerange 20260310-20260925 --breakdown
done

A real result set from a 200-day window (fees included) looked like this:

strategy	timeframe	trades	win%	profit	profit factor	max drawdown
SwingHighToSky	15m	108	68.5%	+1.60%	5.21	0.37%
BbandRsi	1h	62	74.2%	+3.99%	1.38	7.92%
UniversalMACD	5m	6	100%	+1.48%	∞	0.00%

Read that table honestly. UniversalMACD shows a perfect win rate — on six trades. That is not an edge, that is a sample size. BbandRsi has the highest absolute return but a weak profit factor. SwingHighToSky is the only one passing all three filters (PF > 1.5, drawdown < 15%, win rate > 55%) on a statistically usable sample. Pick on the quality of the evidence, not on the biggest number.

Also note: none of them beat buy-and-hold over a window where the market rose ~31%. The dry-run's job is to validate operational behaviour, not to beat the market. Be suspicious of any backtest that does.

The watchdog (the actually interesting part)

Here is a working watchdog, designed to run from cron and stay silent unless something is wrong.

#!/bin/bash
# - restarts the bot if the process died
# - appends a P&L snapshot to logs/daily_pnl.txt on every run
# - SILENT on success; speaks only on restart or risk-limit breach
set -u
BASE=/home/kali/freqtrade
VENV_PY=$(readlink -f "$BASE/.venv/bin/python")
cd "$BASE" || { echo "watchdog: cannot cd $BASE"; exit 1; }
PY=$BASE/.venv/bin/python
LOG=$BASE/logs/watchdog.log
ts() { date -u +"%Y-%m-%dT%H:%M:%SZ"; }

# Print PIDs of the REAL bot processes (empty if none).
find_bot() {
  for p in /proc/[0-9]*; do
    pid=${p#/proc/}
    [ -r "$p/cmdline" ] || continue
    cmd=$(tr '\0' ' ' < "$p/cmdline" 2>/dev/null) || continue
    case "$cmd" in
      *"freqtrade trade --config"*)
        exe=$(readlink -f "$p/exe" 2>/dev/null)
        [ "$exe" = "$VENV_PY" ] && echo "$pid"
        ;;
    esac
  done
}

MSG=""
if [ -z "$(find_bot)" ]; then
  echo "$(ts) bot not running -> restarting" >> "$LOG"
  nohup "$BASE/.venv/bin/freqtrade" trade --config "$BASE/config.json" \
      --strategy SwingHighToSky --dry-run >> "$BASE/logs/trade_stdout.log" 2>&1 &
  sleep 30
  if [ -n "$(find_bot)" ]; then
    MSG="crypto-bot: process was gone, restarted at $(ts)."
  else
    echo "$(ts) restart FAILED" >> "$LOG"
    exit 1
  fi
fi

OUT=$("$PY" "$BASE/monitor_pnl.py" 2>&1); RC=$?
if [ $RC -eq 2 ]; then                      # drawdown limit hit
  for pid in $(find_bot); do kill "$pid" 2>/dev/null; done
  echo "$(ts) DRAWDOWN LIMIT HIT -> stopping bot" >> "$LOG"
  echo "crypto-bot: drawdown >= 10% of wallet. Bot STOPPED by risk rule." 
  echo "$OUT"
  exit 2
fi
echo "$OUT" >> "$LOG"
[ -n "$MSG" ] && echo "$MSG"
exit 0

The gotcha that cost me an hour

Do not detect the process with pkill -f freqtrade or pgrep -f freqtrade. That pattern also matches the shell that invoked your script — because the string freqtrade appears in its command line — and the script kills itself. I hit exactly this. Scanning /proc and requiring both the freqtrade trade --config cmdline and an exe pointing into the venv is unambiguous and safe.

Make it run without babysitting

# every 15 minutes; quiet unless it acts
*/15 * * * * /home/kali/.hermes/scripts/crypto_watchdog.sh

Verify it end-to-end the first time: kill the bot, run the watchdog, confirm the restart and the P&L line. A watchdog you have never seen fire is a watchdog you do not have.

The kill switch is the whole point

The drawdown rule (>= 10% of the wallet → stop the bot) is enforced outside the strategy, in the watchdog. Strategy-level stoplosses protect a trade; this protects the account. Keeping it in one place — not scattered across strategy parameters — means you can reason about your worst case at a glance.

Results after the first hours

wallet=500.10 closed_pnl=+0.000USDT (+0.00%) all_pnl=+0.003USDT (+0.00%) trades=0W/0L open=1

Zero closed trades, one open position, equity essentially flat. That is the correct shape for hour one of a dry-run. The value is not the P&L yet — it is that the clock is now running on a validated, self-healing, risk-capped system, at zero cost.

What to do next

Let it run for two weeks. Judge the behaviour: did the watchdog ever fire? did the kill switch ever trip? how did it behave around a volatility spike?
Hyperopt deliberately — a handful of epochs with a Sharpe-based loss, then re-backtest. Do not hyperopt your way into a curve fit.
Only then consider real capital — and only with an amount you are genuinely fine losing.

The whole setup costs nothing and removes the two failure modes that kill most hobby bots: a dead process and an unenforced risk rule.

If you build on this, the two files worth stealing are the /proc-based process check and the drawdown kill switch. Everything else is configuration.

Related in this series:

The watchdog from this post is open source: **https://github.com/moon-hacks/proc-watchdog* (MIT).*

DEV Community: matteo adorni

Keep Freqtrade running 24/7: systemd vs a zero-dependency watchdog

Option 1: systemd (the "proper" way)

Option 2: cron + watchdog (the pattern I use)

The comparison, honestly

What actually kills unattended bots

I backtested 14 trading strategies. Only one passed my filters.

The setup (so you can reproduce it)

The filter

The results

Why the Sharpe column matters more than profit

What I did with this

The takeaway

Keep any long-running Python process alive on Linux for $0 (the /proc watchdog pattern)

The trap everyone falls into first

The robust check: scan /proc, and require two things

The full watchdog

Why "silent on success" is the important part

The safety rule lives outside your app

Scheduling

Test it, or you do not have one

The cost

Run a self-healing crypto trading bot 24/7 for $0 (Freqtrade + watchdog)

Why a watchdog matters more than the strategy

Prerequisites

A minimal, sane config

Backtest before you believe anything

The watchdog (the actually interesting part)

The gotcha that cost me an hour

Make it run without babysitting

The kill switch is the whole point

Results after the first hours

What to do next

The robust check: scan `/proc`, and require two things