Crypto Alert Hub With Discord Delivery: A Paper-Only Workflow

A useful crypto alert hub should separate four jobs: detect the market event, verify that it is still fresh, review it with current bot context, and deliver the result to Discord. Discord is the final communication channel—not the source of the trade thesis and never permission to buy or sell.

TradingWizard can help a trader inspect a supported asset through bot scans, current states, reasons, and paper-mode records. Every TradingWizard bot uses fake money against real market data. TradingWizard does not place, modify, or close real orders.

The workflow at a glance

Want to test the review step? Choose a supported asset and deploy a paper bot in Wiz. Start with one market and confirm the state, reason, and timestamp before adding Discord delivery.

Why Discord should be the last mile

Discord is good at distributing concise messages to a team or community. It is not a market-data validator, a risk engine, or evidence that a setup exists.

A Discord message can arrive late, repeat, lose context, or be copied into another channel. If the message contains only BTC BUY, the reader cannot tell:

• what condition fired;
• when it happened;
• whether the market has already moved;
• where the setup becomes invalid;
• whether the source retried the same event;
• whether the bot currently says WAIT or AVOID;
• whether the activity is simulated.

The hub should do that work before delivery.

Start with a structured trigger

TradingView's alert documentation describes price, technical, drawing, strategy, and watchlist alerts. These are notifications that a saved condition changed. They are not proof that a complete trade setup exists.

A trigger record should include:

• a stable alert ID;
• the asset and venue or data source;
• the timeframe;
• the saved condition and version;
• the source event time with timezone;
• the received time;
• a short reason for review.

If the alert came through a webhook, preserve the original payload safely. Never put credentials, passwords, private keys, or personal account data in a Discord message or webhook body.

Verify webhook delivery instead of assuming it

TradingView's webhook guide says alert webhooks are HTTP POST requests to a configured URL. It warns that webhooks can occasionally fail and recommends checking the Webhook status column in the alert log. It also says slow remote endpoints can be cancelled.

That creates two separate facts:

1. the alert condition triggered;
2. a receiving service accepted the delivery.

Record both. A green sender state is not enough if the hub never received the event, and a Discord message is not enough if no one can trace it back to the original condition.

Add a freshness gate before bot review

Crypto trades around the clock, but not every alert stays useful. A fast-moving condition can be outdated by the time a message is opened.

The hub should compare:

• event time;
• received time;
• current time;
• alert timeframe;
• current price or market state;
• any invalidation that occurred after the trigger.

If the necessary data is old or missing, stop with DATA STALE. If the event's useful window has passed, use EXPIRED. Do not dress an old trigger as a current setup.

Let the bot explain the current state

The TradingWizard workflow is bots-first: choose a supported asset, deploy a bot, and inspect each scan. A bot scan may show a defined setup with entry, stop, target, invalidation, confidence, and risk context when available. It may instead show WAIT, AVOID, DATA STALE, RISK BLOCKED, or EXPIRED.

Those no-trade states are useful. They prevent a delivery system from turning every market event into an instruction.

For a deeper comparison of roles, see AI Trading Scanner vs Setup Engine vs Bot.

Design the Discord message for review

A concise Discord alert can use this structure:

Do not include a private account number, access token, webhook secret, portfolio balance, or personal position. Keep server membership and role permissions appropriate for the information being shared.

Route by importance, not by volume

Not every event deserves Discord.

Use in-app history for low-priority records and repeated scans. Use Discord when the event is timely, relevant to the configured audience, and meaningfully different from the previous state. A digest can collect lower-priority updates.

A practical routing policy might be:

• DATA STALE: log it and notify only if the outage matters;
• WAIT: keep it in the timeline unless the state materially changed;
• AVOID: preserve the reason; deliver only when subscribers asked for risk warnings;
• RISK BLOCKED: notify the user who owns the rule;
• defined paper setup: deliver with timestamp, levels, reason, and paper label;
• duplicate event: group it with the original record.

Test the workflow safely

Use this checklist before expanding to many assets or channels:

1. Pick one supported asset.
2. Create one harmless alert condition.
3. Record the event ID, source time, and condition version.
4. Send the event to a test endpoint with no secrets in the payload.
5. Verify the hub's received time and delivery status.
6. Inspect the current TradingWizard paper-bot state.
7. Confirm that a no-trade state stays a no-trade state.
8. Deliver one sanitized message to a private Discord test channel.
9. Retry the same event and verify deduplication.
10. Open the message after its useful window and verify stale or expired handling.
11. Review the paper record after the market moves.
12. Keep every real-money decision outside TradingWizard.

What paper mode can and cannot tell you

Paper mode can reveal whether the workflow preserves timestamps, follows its rules, handles no-trade states, and records changes consistently. It cannot prove profitability or reproduce every real fill condition.

Alpaca's paper-trading documentation notes that simulations may not account for market impact, information leakage, latency-driven slippage, order queue position, price improvement, fees, or dividends. The CFTC also warns that AI cannot predict the future or sudden market changes and that guaranteed-return claims are a red flag.

Judge the process, not a screenshot of one favorable result.

Common failure modes

The Discord message has no timestamp

Readers cannot judge whether the event is current. Include the event time and freshness state.

The webhook is treated as guaranteed

Sender, receiver, and destination can fail independently. Preserve status at each step.

Every trigger becomes a setup

A trigger only says a condition changed. Require a current bot or human review and allow WAIT, AVOID, stale, expired, and blocked outcomes.

The alert exposes secrets

Never put credentials or private account data in webhook bodies or Discord messages. Use authenticated receiving endpoints and minimal payloads.

Paper results are presented as investment performance

Label simulated activity clearly and show losses, skips, and failures alongside favorable outcomes.

Bottom line

Build the workflow in this order: structured trigger, verified receipt, freshness check, current bot review, selective Discord delivery, and a paper-mode record. Discord should carry context, not manufacture certainty. If the state is stale, blocked, or waiting, the message should say so plainly.