Why isn't my alert reaching Autoview?
There are two different problems that both look like "nothing happened," and they need different fixes. One is an alert that reached Autoview and then failed somewhere in parsing or execution, that's what the common error messages guide and the testing and debugging guide cover. The other is an alert that never reached Autoview at all, or arrived and got rejected before a single command was read out of it. This guide is about that second problem: the one where your Autoview log has no entry to even start debugging from.
Start here: open your Autoview log for the time the alert should have fired. Reading your log covers where to find it. If there's genuinely nothing there, not even an error, the request either never left the sender or never reached Autoview's webhook. If there's a rejection entry, read on, the next section is probably it.
The silent rejection: your alert message looks like JSON
Autoview's webhook expects a plain command string in the body of the request, the same e= s= b= syntax used everywhere else on this site. It checks the request's Content-Type header before it reads any of that: plain text or an unrecognized type gets processed normally, but a request sent as JSON, as a web form, or as multipart form data is rejected outright, before Autoview looks at the commands inside it.
Here's the part that catches people out. Some alert senders inspect the message text and set the Content-Type header automatically. If your alert message happens to be syntactically valid JSON, even by accident, a sender can switch to sending it as application/json, and Autoview's webhook turns that request away with a 415 Unsupported Media Type response. Nothing executes, and nothing about your command syntax was wrong. The fix is the message itself: keep it a plain command string, not something that parses as a JSON object, and the request goes through as text again.
This shows up in the log as Unsupported Media Type provided: json. (or form / data, depending on what the sender sent). If you see that line, this is exactly what happened, look at the raw alert message and check whether it accidentally forms valid JSON.
On the sending side: TradingView's own delivery rules
Autoview's webhook accepts a POST from any sender, TradingView is the common one but not the only one. These three requirements are TradingView's own, not Autoview's, and TradingView won't necessarily tell you plainly which one you hit, so they're worth checking directly.
- Two-factor authentication is required. TradingView only allows webhook alerts on accounts with 2FA enabled. If it isn't on, a webhook alert can't be created or won't fire, no matter how the alert itself is configured.
- Alerts expire. An alert's maximum lifetime is two months unless it's set open-ended, which requires TradingView's Premium or Ultimate plan. An expired alert produces nothing: no fire, no request, no entry anywhere in Autoview's log. If an alert that used to work just stopped, with no error to chase, check whether it quietly expired before you assume the webhook is broken.
- Long-idle alerts get auto-deactivated. TradingView turns off an alert once it's more than a year old, hasn't triggered in over a year, and hasn't been edited in over a year, all three at once. Unlikely to hit a fast-moving strategy, but a real cause for something set up once and left alone.
TradingView also caps how long it waits for a response, and rejects unusual delivery configurations (non-standard ports, IPv6 endpoints) outright. None of that touches Autoview, since Autoview's webhook already runs on a standard endpoint, but it's worth knowing if you're troubleshooting a custom or self-hosted receiver alongside Autoview.
Autoview's own response time isn't the bottleneck
Worth ruling out explicitly, since it's a natural thing to suspect: Autoview acknowledges a webhook request immediately on receipt, before it has placed any order on any connected exchange. The response confirming Autoview got the request comes back right away, independent of how long the actual trade takes to execute afterward. If an alert is timing out on the sending side, that delay isn't coming from Autoview's own processing.
Once the alert is actually arriving
If you've ruled out a content-type rejection and the delivery-side checks above, and your log shows the alert did arrive, you're past this guide's scope and into the next two: common error messages covers what a logged rejection means once Autoview or the exchange has seen the request, and testing and debugging covers using d=1 to dry-run a command and catch syntax problems before they cost anything.