RelayDM
When Instagram DM automation keeps failing, diagnose the first unproven transition rather than rebuilding the entire flow. A connected account, a received event, a queued job and an accepted message are separate facts. A stage-based incident record makes failures easier to reproduce and reduces the temptation to send again without knowing what happened.
Check permission before interpreting activity
Start with the correct professional account and current connection. Confirm whether authorization is valid and whether the required capability applies to this account and message context. A green account card is helpful, but it does not prove every proposed operation is authorized.
If an access token expires or a permission is removed, refreshing the browser cannot repair provider authorization. Preserve the sanitized error and use the documented reconnect path. Do not copy credentials into a support ticket or use another account’s evidence because the usernames look similar.
Separate event arrival from event acceptance
A webhook request may reach the edge but fail signature validation, account mapping or parsing. Ask which signed event was accepted, when it arrived and which workspace it mapped to. A screenshot of the original comment is not equivalent to application ingestion evidence.
Preserve a safe correlation reference instead of raw tokens or full personal message bodies. If the event never arrived, investigate provider subscription or delivery configuration. Changing the message composer is unrelated to an absent inbound event.
Inspect durable work and containment
After acceptance, determine whether durable work was created and whether a worker may claim it. A queue notification is not the same as a completed job. Delayed database operations, expired leases and revoked authorizations need explicit recovery behavior.
An illustrative incident record might say “event accepted, job stored, send blocked by expired grant.” That is more useful than “automation broken.” Do not remove containment to make the queue move. The stopped job may be the system correctly enforcing an expired or revoked permission.
Distinguish provider rejection from uncertainty
If a send was attempted, inspect the actual provider response and message reference. A rejected format differs from a network timeout after a request may have reached Meta. The latter must not be treated as proof that nothing was sent.
Avoid blind retries after an uncertain outcome. First reconcile what can be established and preserve the original attempt. A durable job identifier and idempotency design help prevent a browser refresh or duplicate webhook from creating a second independent send.
Check what the recipient can actually observe
Provider acceptance and visible delivery are related but different observations. A message may appear in Requests, or a particular structured format may not render as expected. Use one controlled consenting recipient when live acceptance is explicitly authorized.
Do not create synthetic success events to replace missing evidence. Read the first-failed-step guide and platform limitations guide before deciding whether a repeat test is appropriate.
Build a concise incident packet
Include the approximate time, workspace reference, account, post, expected action, first failed stage and sanitized request or job references. State whether any provider attempt may have occurred. Keep secrets and unrelated customer data out. Use rule-level troubleshooting only when matching is actually uncertain. RelayDM’s current availability remains authoritative; diagnosis must not bypass financial or sending gates.
Sources and editorial notes
Source review: November 1, 2026. This is research-based guidance, not an independent hands-on test of every product. Prices and permissions can change.
Read our methodology, product-availability policy and corrections process.
