TradingView Alerts on MT5: The Part Every Guide Skips

If you've spent time trying to connect TradingView alerts to MetaTrader 5, you've probably noticed that every guide ends at the same frustrating point: "paste this URL into your TradingView alert." Then nothing. No mention of what needs to be running on the other end, what happens when it crashes at 3 AM, or why your broker's symbol names don't match TradingView's.

This is that guide. The one that explains the gap.

The fundamental problem

TradingView fires webhook alerts as HTTP POST requests. You give it a URL, it sends JSON when your conditions are met. That part is simple and reliable.

MetaTrader 5 has no webhook receiver. None. It's a Windows desktop application that runs Expert Advisors (MQL5 programs attached to charts). Those programs tick on price updates. They can't sit and wait for incoming HTTP requests.

So you have a sender (TradingView) and a receiver (MT5) that speak completely different languages, and nothing bridging them out of the box.

What actually has to happen

The chain between an alert firing and an MT5 order executing has five links:

1. Receive the webhook. Something has to be listening on an HTTPS URL 24/7. This is a web server: your own server, or a hosted service.

2. Authenticate it. TradingView doesn't sign its webhooks. Anyone who knows your URL can send fake signals. You need a shared secret in the payload or a header check.

3. Parse and validate the payload. The JSON TradingView sends is exactly what you typed in the alert message box, with template variables substituted. If your JSON is malformed or missing a field, you want to know that before trying to place an order.

4. Translate it into an MT5 instruction. The symbol name from TradingView (BTCUSD) almost certainly doesn't match your broker's symbol name (BTCUSDm, BTC/USD, or whatever suffix they use). Volume needs to be checked against allowed lot sizes. This is where most DIY setups have silent bugs.

5. Get the instruction into MT5. This usually means the MetaTrader5 Python library, which requires the MT5 terminal to be running and logged in on the same machine (or a machine it can reach). If the terminal isn't running, nothing happens. And you might not find out for hours.

Every one of these links can fail independently.

The DIY Python bridge

The most common approach is a Python script: Flask or FastAPI to receive the webhook, the MetaTrader5 library to talk to the terminal. The code isn't complicated. You can get something working in an afternoon.

The problem isn't writing it. The problem is keeping it running.

Three months in, here's what typically goes wrong:

The script is running in a terminal window or a tmux session. Someone (maybe you) reboots the server without restarting it. Or the server reboots itself for a security update at 4 AM. The script doesn't come back up.

The MT5 terminal closes because Windows decided to install updates. Or your broker's server went down briefly and the terminal didn't reconnect. The Python library calls succeed (no exception thrown), but the orders go nowhere.

TradingView fires an alert twice for the same bar because the condition was true across two ticks. You get two orders.

None of these failures are loud. There's no exception in your face. The alert fires in TradingView. You can see it in the alerts log. Nothing shows up on the broker side. You find out later, maybe much later.

This is the babysitting problem. The technical solution is easy. The operational solution is what kills you.

Fixing it yourself means: systemd or supervisor for process management, a health-check endpoint, a watchdog that pings the MT5 terminal and alerts you if it's not responding, deduplication logic with a small database or in-memory cache, and retry logic with exponential backoff. That's weeks of infrastructure work before you've placed a single live trade.

Third-party connectors

There are services that sit between TradingView and MT5. You install their EA, point your alerts at their servers, and they route orders through. Some are good. The concerns are:

Your orders flow through someone else's infrastructure. That means their servers see your trade signals. For anyone trading anything meaningful, that's uncomfortable.

The EAs are usually closed-source. You're trusting code you can't read to touch your live account.

The services can change their pricing model, get acquired, or shut down. If you build a strategy around one of them, you're locked in.

For low-stakes experimentation, this might be fine. For anything you're running serious capital on, it's worth thinking about.

What a proper self-hosted setup looks like

The architecture that actually works: an agent process running on your server, acting as the webhook receiver, validator, translator, and MT5 connection manager all at once.

It's designed to run as a system service — it starts on boot, restarts automatically if it crashes, and writes structured logs. The webhook URL looks like https://your-server/agent/your-id/webhook. TradingView sends to that URL. The agent handles everything from there.

The things a proper agent does that your Flask script doesn't:

Symbol mapping. You define a table: BTCUSD → BTCUSDm. The agent translates before placing orders.

Deduplication. Each alert gets a hash. If the same signal arrives twice within a window, only one order goes through.

Terminal health checks. The agent verifies the MT5 terminal is running and responding before accepting signals. If it isn't, the alert is queued or rejected with a clear error. Not silently dropped.

Status visibility. You can see whether your agent is running, what its last signal was, and whether it placed an order, without SSH-ing into the server.

This is what Bullion does. It's self-hosted (you run it on your own server, your credentials never leave your infrastructure), open source, and designed around the operational reality of running automated strategies rather than the toy scenario of "fire one trade manually."

The payload format is half your problems

One thing almost no guide covers: the TradingView alert message field is a template, and the variables it substitutes are a source of constant pain.

{{ticker}} gives you the TradingView symbol, which may not match your broker's symbol at all. {{exchange}} gives you the exchange, which you probably don't need. {{close}} gives you the bar's closing price. Useful, but note that if your alert fires mid-bar, it's the current price, not the close.

A well-structured payload looks something like:

{
  "symbol": "{{ticker}}",
  "side": "buy",
  "volume": 0.1,
  "secret": "your-shared-secret",
  "comment": "TV-{{time}}"
}

The secret field is how you authenticate that the signal came from TradingView and not someone who guessed your endpoint URL. The comment field gets attached to the order in MT5, making it much easier to trace a live order back to the alert that triggered it.

Keep the payload simple. Don't try to encode complex logic in it. The agent or script on the other end should have the logic; the payload should just tell it what to do.

The version of this that actually stays running

If you want to build this yourself and have it hold up in production, the minimum stack is:

• FastAPI (or any WSGI framework) for the webhook server
• MetaTrader5 Python library for order execution
• supervisor or systemd for process management (not just running in a terminal)
• A small SQLite or Redis store for deduplication
• A Telegram bot or similar for alerting when things go wrong

That's a real project. Realistically two weekends to do properly, then ongoing maintenance as the MT5 library updates and your broker changes things.

Alternatively, Bullion handles all of this. You install the agent on your server, add your MT5 credentials, configure your symbol mappings, and get a webhook URL. The operational overhead is handled.

Either way, understanding the full chain matters. The worst thing you can do is set something up, assume it's working, and find out in a month that half your alerts were silently failing.

---

If you found this useful, the Bullion docs walk through a full setup in more detail, from installing the agent to connecting your first TradingView strategy.