Investigate why a Resend email did not arrive or why an app missed its event. Trace the message status, API request logs, suppression records, sending-domain checks, and webhook attempts to identify where delivery or reporting stopped.
Find out why an email sent with Resend did not arrive — find the email, read its status, then check the API log, the suppression list, the sending domain, and the webhook that should have reported it. Use when the user says an email never arrived, went to spam, bounced, or that their app's sends or webhooks are failing.
Run score Not tested
See how to installWhen a Resend email does not arrive, this skill searches by recipient, subject, and send time, then checks the message status to trace the cause. If no email is found, it checks API logs for a rejected request. If a message exists, it follows its status: queued, delayed, delivered, bounced, or suppressed. It can inspect the receiving server's response, suppression records, and DNS records for the sending domain. If an app did not receive a delivery event, it checks the webhook configuration and event attempt results.
Use it to investigate reports that email never arrived, went to spam, or bounced. It also helps when the email itself is fine but an app did not receive its webhook notification. It can show where delivery stopped before anyone tries sending the message again.
Removing an address from the suppression list is allowed only after the cause is fixed and the user requests it. Resending a delayed email may deliver duplicates.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).
Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 30, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
An email that "never arrived" stopped at one of four points: Resend never accepted the request, Resend did not send it, the receiving server rejected it, or it arrived and the user did not see it. Find the point before you change anything.
Run list-emails and match the recipient, subject, and time. Then run
get-email on the match.
If there is no match, the request did not succeed. Go to step 2.
Run list-logs and find requests to /emails near the time of the send. Run
get-log on any request that did not return 2xx. The response body names the
cause, for example a domain that is not verified, a field that is not valid, or
a rate limit. Quote it to the user.
The status in get-email tells you what to do next:
queued, scheduled: not sent yet. A scheduled email waits for its time.sent: Resend accepted it, and the receiving server has not answered yet.
Look again after a few minutes.delivery_delayed: the receiving server is deferring it. Resend tries again.
Do not send it again.delivered, opened, clicked: it arrived. Tell the user to look in spam,
promotions, and any mail filters, then go to step 5.bounced: the receiving server rejected it. Go to step 4.complained: the recipient marked it as spam.suppressed: Resend did not send it, because the address is on the
suppression list. Go to step 4.failed, canceled: it was not sent. Read the details, and look for the
request in step 2.Run get-suppression with the address. The origin tells you why it is there:
bounce (a hard bounce), complaint (a spam report), or manual. Resend does
not send to a suppressed address again.
Remove an address only when the user asks, and only after they confirm that the cause is fixed. If an address bounced or complained and you send to it again, it hurts the sender reputation of the domain.
Run get-domain on the sending domain. A DNS record that is not verified
(SPF, DKIM, or the MX record for the return path) is the usual cause of mail
going to spam. Show the user each record and its status. For a pattern across
many emails and not one, run get-email-metrics for the period, by domain.
When the app missed the event and not the email, run list-webhooks, then
list-webhook-events on the right webhook. An event with the status failed
or attempting has its cause in list-webhook-event-attempts: the HTTP status
and the body that the user's endpoint returned.
sent. It is not the end of the path. Look again.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Review how you use Superset and identify unused features that fit your workflow. Get a short list of suggestions, learn about each option, and set up selected features such as scheduled agents, parallel workspaces, or shared tasks.
Set up recurring tasks in Superset with an agent prompt, a schedule or event trigger, and a chosen execution workspace. After explicit confirmation, create the automation, check its saved settings, and review a real first run.
Browse pages, click controls, fill fields, and inspect screenshots or console messages through Superset's browser pane. Use it to preview a running web app, check interface behavior, and work through browser tasks in a visible session.
Build Stripe payments, subscriptions, and invoicing using verified documentation and API parameter definitions. The skill guides product selection, sandbox testing, and webhook handling, where server notifications determine payment and subscription state.
Verify a UI change or reproduce a bug in the running desktop app using the Chrome DevTools Protocol (CDP), a browser debugging interface. Follow the real user journey and compare screenshots with measurements such as route, scroll position, and persisted state.
Diagnose failed GitHub Actions runs by finding the first meaningful error, separating code problems from infrastructure issues and intermittent failures, and comparing the base branch. Get a focused report explaining the PR’s involvement and recommended next steps.