Choose one concrete example: which instance, rule, new source message, and destination are affected? Use that same message throughout the investigation.
1. Check the instance and source
Confirm the instance is running and the source account belongs to it. Check the source connection, latest heartbeat time, and rule readiness in instance and source status. Runtime logs show health changes, error categories, and recovery events. Routine heartbeats and ordinary received-message events are hidden by default; a quiet log alone does not mean the source is offline.
An online node proves communication with the node, not a working account login. A signed-in account also needs an enabled rule and a ready listener. Resolve expired Discord tokens, Telegram verification, or pending QQ login in the corresponding account screen.
2. Check the source channel and rule
- Confirm the correct account and source channel are selected and the rule is enabled.
- For Discord, check channel or thread IDs. For Telegram, check the numeric Chat ID and minus sign.
- Check trigger keywords, block keywords, sender restrictions, receive-bot-messages, and receive-own-messages settings.
- Test a new message created after listening is ready; do not assume old history is automatically replayed.
- For multiple destinations, inspect each named destination result.
If no Delivery record exists, start with these checks. Messages rejected by source-side filtering may never create a destination record. Keywords match text, including words inside negative statements; they do not verify meaning or sender authenticity.
3. Read the delivery state
| State | Meaning | Next step |
|---|---|---|
| Queued | Waiting to be sent | Wait; report persistent backlog |
| Delivering | Send in progress | Refresh later; avoid repeated manual retries |
| Waiting for retry | An attempt failed and may be retried | Read the error and check permission or network |
| Needs attention | A failure needs review | Fix the cause before considering redelivery |
| Blocked by OCR | Image text matched a blocking rule | Check the image and OCR keyword list |
| Delivered | A successful result was recorded | Confirm real content and channel placement at the destination |
| Rule deleted | The related rule was removed or archived | Confirm whether the route is still wanted |
Redelivery sends a real message and may notify people again. Confirm the destination has not already received the message and the underlying fault is fixed before retrying.
4. Check destination credentials and permissions
- Discord Webhook: valid complete URL, correct parent channel and thread.
- Discord Bot: installed bot, correct channel ID, and channel permission overrides.
- Telegram Bot: correct Chat ID, group membership or channel administrator rights; private users must start the bot.
- Feishu or DingTalk: webhook, signature secret, required keywords, and any IP restrictions.
- Bark or Gotify: destination URL, credential, client connectivity, and notifications.
- Email: SMTP authorization, recipient, filters, and spam folder.
Some saved credential fields are blank when editing because secrets are not shown again. Leave the field alone unless you intend to replace that credential.
If only attachments or translation fail
Verify plain text first. Then test one small image or a short translated message separately. Check attachment settings, destination size limits, source media access, and available translation or vision processing.
Text receipt does not validate video, watermarking, or translation. Read the specific error instead of repeatedly restarting the instance. Target edit/delete sync and consistency checks depend on connector capabilities; consistency checks are available only for supported Discord Bot destinations.
Duplicate messages and partial recovery
Check overlapping rules, multiple target configurations, source-to-destination loops, and previous manual redelivery. The same announcement posted separately on Discord and Telegram is two different source events. For missing messages, check filters, source history boundaries, and platform restrictions.
Use a new test identifier after a change. One successful test does not prove all earlier queued messages were recovered. Telegram does not scan history; Discord's optional history recovery has separate bounds from delivery retry.
Contact support safely
Submit My feedback with the time and timezone, instance and rule names, source and destination types, a redacted test identifier, the delivery state, a redacted error, whether the destination received duplicates, and recent changes.
Do not include account tokens, full webhook URLs, SMTP passwords, verification codes, two-step passwords, or node enrollment keys. Redact screenshots too. Deleting an entire instance is not a diagnostic step: it removes related resources and credentials.
Getting started · Discord guide · Telegram guide · All documentation