My TradingView alert log shows it fired. Why is nothing in my Autoview log?

TradingView confirming an alert fired only means TradingView evaluated the condition and sent the webhook request. It says nothing about whether Autoview accepted that request. Check your Autoview log first: if there's no entry at all for that time, the request never arrived or was rejected before Autoview logged it, which points at the sending side, not at Autoview's parsing.

Does Autoview reject an alert message sent as JSON?

Only if it's the wrong shape. Autoview accepts a JSON body today: a bare JSON string, or an object with a string "alert" field, for example {"alert": "s=BTCUSDT b=buy q=1 t=market"}. A JSON body in any other shape gets a 400, not a 415. What's still rejected outright, with a 415, is a form-encoded or multipart body, the default some HTTP clients fall back to when no Content-Type is set explicitly.

Does Autoview's own processing time ever cause a webhook alert to time out?

No. Autoview acknowledges a webhook request immediately, before it finishes placing any order on a connected exchange, so the response comes back well within any sender's timeout window. If an alert times out on the sending side, the delay isn't coming from Autoview's own response.

What does "request took too long and timed out" in TradingView's alert log mean for an Autoview webhook?

TradingView waited 3 seconds for a reply and then cancelled the request. Autoview replies before it places any order, so the delay isn't trade execution. A timeout row doesn't prove the request never arrived, so check your Autoview log for that minute before you fire the alert again by hand, or the same order could go in twice.

Which HTTP status codes can Autoview's webhook send back?

A 200 when it accepts the request. Its rejections are all 4xx: 415 for a form or multipart body, 400 for JSON in the wrong shape, 404 when the identifier in the URL doesn't match a webhook, 401 for a missing or wrong webhook key, 411 for a message with no commands in it, and 422 when no exchange account is linked to the webhook. TradingView doesn't resend 4xx responses. It only resends on a 500 to 599 status, and never on a 504.

Why would an alert that used to fire just stop, with no error anywhere?

On TradingView specifically, an alert has a maximum lifetime and can expire silently, or auto-deactivate after a long stretch with no trigger and no edit. An expired or deactivated alert produces nothing: no fire, no webhook request, no entry in Autoview's log. That's a different failure than a rejected request, and the fix is on the alert itself, not the webhook.

Why isn't my alert reaching Autoview?

Autoview · Guide · Updated October 5, 2026

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: form-encoded and multipart bodies

Autoview's webhook reads a plain command string out of the request body, the same s= b= q= syntax used everywhere else on this site, and it reads that same command out of a JSON body too: either a bare JSON string, or an object carrying it under a string "alert" field. It checks the request's Content-Type header first: plain text (or an unrecognized type) and JSON both get processed, but a request sent 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 HTTP clients default to a form-encoded body when no Content-Type is set explicitly, curl's -d flag is the classic example, 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 setting Content-Type explicitly: text/plain for the plain command string, or application/json if you're sending it wrapped in JSON.

A JSON body gets a different rejection if the shape is wrong, say your alert message parses as JSON but isn't a bare string or an object with an "alert" field. That's accepted as JSON and then rejected with a 400, not a 415: a different failure than the content-type rejection above, but still nothing executed.

These rejections don't appear in the default Event Log. They're recorded in your webhook's history, and in the Event Log's threaded view, as Unsupported Media Type provided: form. (or data, for multipart) for the 415 case, or Unsupported JSON body shape provided. for the 400 case. If you see either line, look at the raw alert message and the Content-Type your sender used.

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.

What the Webhook status column in TradingView's alert log means

TradingView records each webhook delivery in its alert log, in a column called Webhook status. That column is the sender's side of the story, so it's the first thing to read when your Autoview log (the Event Log in your account) has nothing for the time an alert fired. TradingView's Help Center groups the errors it can show into ten kinds. The quoted phrases below are TradingView's own wording, and the note after each one is what it means when the URL points at Autoview.

"request took too long and timed out". TradingView waits 3 seconds for a reply and then cancels the request. Autoview replies before it places any order, so a slow fill can't cause this. A timeout row also doesn't prove the request never arrived. Check your Autoview log for that minute before you fire the alert again by hand, or you may place the same order twice.
"this URL isn't allowed", "couldn't find this domain" or "the server couldn't be reached". TradingView couldn't use the URL at all, and a typo is the usual cause. Copy the webhook URL again from your Autoview account. It looks like https://api.autoview.com/hook/<identifier>/, with ?key= and your key on the end if the webhook has one.
"IP isn't allowed". The URL resolves to a local or private address. Autoview's webhook sits on a public address, so this means the alert is pointed somewhere else, such as a test receiver on your own network.
A 4xx status. The request reached Autoview's webhook and was turned away. Autoview's own rejections are 415 (form or multipart body), 400 (JSON in the wrong shape), 404 (the identifier in the URL doesn't match a webhook), 401 (the webhook has a webhook key and the request didn't carry it), 411 (the message had no commands in it) and 422 (no exchange account is linked to the webhook). TradingView doesn't resend any of these.
A 5xx status. Autoview's webhook never returns one on purpose, so a 5xx points at an infrastructure failure on the receiving side. It's also the one class TradingView retries: for any status from 500 to 599 except 504, it resends after 5 seconds, up to 3 times. Does TradingView resend webhook alerts? covers what that means for duplicate orders.
Anything else. That covers a 3xx redirect, a secure connection error, "server refused the connection", "server sent an invalid response" and "something went wrong". None of them come from your alert message or your command syntax. If one keeps showing up across several alerts while your Autoview log stays empty, contact Autoview support and include the alert times.

Two of those rejections also leave a trace on Autoview's side. A 401 for a missing or wrong key and a 422 for an unlinked webhook each write an entry to your Event Log, so you can confirm the rejection from both ends. A 404 writes nothing, because Autoview can't tell which account the request was meant for. If the alert log shows a 404, check the identifier part of the URL first.

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.

A decision tree for "nothing happened"

Walk these in order. Each answers one question and points at the next check, rather than guessing at the whole chain at once.

Did the sender confirm delivery? Check the sending platform's own delivery status first (TradingView's alert log, or your script's own HTTP response). If the sender itself shows the request never went out, the problem is upstream of Autoview entirely.
What HTTP status came back? A 415 means a form-encoded or multipart body, before any command was read. A 400 on a JSON body means Autoview accepted the content type but the shape wasn't right, check it's a bare JSON string or an object with a string "alert" field. A connection failure or timeout on the sender's side means the request may never have reached Autoview's webhook at all.
Is there anything in Autoview's log for that timestamp? Nothing at all means the request didn't arrive or was rejected before logging. An entry means Autoview received and acknowledged it, whatever happened next. Autoview's own internal processing tags each accepted request with an ID for tracing, though that ID isn't currently a labeled field in the exported log; the timestamp is what ties a log entry back to a specific alert fire.
If it arrived, what did Autoview's parser do with it? The log line shows the parsed result. A parse failure or an unrecognized parameter is a syntax problem, covered in common error messages, not a delivery problem.
If it parsed, what did the venue say? The exchange's own response, visible in the same log entry, is the last link in the chain. A rejection here is exchange-side (permissions, symbol, size), not a delivery or parsing issue.

On retrying: resending an alert that already arrived, when you're not sure whether it was accepted the first time, can place the same order twice. Check the log for an existing entry at that timestamp before firing a duplicate, the same discipline that matters after an exchange returns an ambiguous response. Don't put an API key, a webhook secret, or any other credential in the alert message body unless the command actually requires it; a message body can end up in logs, screenshots, or exports, per the redaction guidance in reading your log.

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.

Go to your log