A Resend dashboard for the mail that has to arrive
Delivery, bounce, and complaint rates for one sending domain — the numbers that decide whether your mail arrives at all.
Get early access to the Resend integration
dev-views is in active development. Join the waitlist and we will note your interest in Resend.
Transactional email fails quietly. A password reset that bounces produces no exception, no failed deploy, and no error in your logs — just a user who cannot get in and does not tell you. By the time a sending reputation problem is obvious, it has usually been building for weeks.
dev-views reads one Resend sending domain and tracks the figures that predict this rather than report it. Bounce rate above 5% puts sending at risk. Mailbox providers expect complaint rate under 0.3%. Both are readings on a tile, next to how much you actually sent and how much of it arrived.
What dev-views reads from Resend
29 readings, computed from the Resend API. There are no defaults — you choose which become tiles and in what order, because guessing which of 29 matters to you would be wrong for most people.
Delivery rate
The share of sent email that reached the recipient's server. Taken from Resend's own metrics endpoint rather than recomputed, so it agrees with what their dashboard shows.
Bounce rate
The share of sent email that bounced. Above 5% puts your ability to send at risk, which is why it is a headline rather than a detail.
Complaint rate
The share of delivered mail marked as spam. Mailbox providers expect this under 0.3%, and exceeding it is how a sending domain gets throttled.
Suppressed addresses
Addresses Resend will no longer send to, split by whether they were suppressed after bouncing or after complaining. A growing list is a growing silent-failure surface.
Domain status
Whether the domain is verified for sending, with the count of DNS records Resend can currently see.
The full list
- Sent, 30 days
- Sent, 7 days
- Sent today
- Delivered, 30 days
- Delivery rate
- Bounced, 30 days
- Bounce rate
- Failed, 30 days
- Delayed, 30 days
- Suppressed, 30 days
- Last send
- Opens, 30 days
- Open rate
- Clicks, 30 days
- Click rate
- Unsubscribes, 30 days
- Unsubscribe rate
- Spam complaints, 30 days
- Complaint rate
- Suppressed addresses
- Suppressed after bouncing
- Suppressed after complaining
- Domain status
- DNS records verified
- Region
- Open tracking
- Click tracking
- Added
- API keys
How the connection works
- 01Create an API key on Resend's API Keys page. It needs full access — sending access cannot read metrics.
- 02Paste it into dev-views, which verifies it against the Resend API before storing anything.
- 03Pick the sending domain to watch from those on the account.
- 04Choose which of the 29 readings become tiles.
- Credential
- A API key (re_…), created under API Keys.
- Watches
- One domain, chosen after connecting.
- Refresh
- Every 60 seconds, cached per user so browsing does not re-spend your API budget. A manual refresh forces a read immediately.
- Storage
- Encrypted with AES-256-GCM before it is stored. The encryption key lives in the environment, never in the database, and the credential is never sent back to the browser.
Reading domains and metrics needs a full access key. Resend offers only full access or sending access, with nothing narrower, and the metrics endpoints are not covered by the sending-only level. That same key can send mail as you and delete a domain. dev-views only ever reads and encrypts the key with AES-256-GCM before storing it, but treat it as you would your password.
What your dashboard shows
- Rates and counts side by side, because 40 bounces means nothing without knowing whether you sent 400 emails or 40,000.
- Reputation as its own group rather than a footnote under delivery — complaints, suppressions, and the two reasons an address ends up suppressed.
- Engagement readings that state their dependency: opens need open tracking enabled, clicks need click tracking, and the domain group shows whether each is on.
- A failing delivery rate or an unverified domain raised in the attention band above the dashboard even without a tile for it.
Who this is for
- Solo developers sending transactional mail — password resets, confirmations, receipts — who need to know when it stops arriving.
- Anyone running a double opt-in flow where a bounce means a signup silently never completes.
- Developers who have never checked a complaint rate and would rather not learn about it from a throttled domain.
Resend questions
Which Resend metrics does dev-views track?
Twenty-nine readings for one sending domain: delivery covering sent counts for today, 7 days, and 30 days, delivered, bounced, failed, delayed, suppressed, delivery and bounce rates, and time since the last send; engagement covering opens, clicks, unsubscribes, and their rates; reputation covering spam complaints, complaint rate, and suppressed addresses split by bounce and complaint; domain facts including verification status, DNS records seen, region, and whether open and click tracking are enabled; and the account's API key count.
Why does dev-views need a full access Resend key?
Because Resend does not offer a read-only one. Its keys come in full access or sending access, and the domain and metrics endpoints dev-views reads are not available to a sending-only key. This is stated plainly on the connect screen rather than glossed over, since that key can also send mail as you. The key is encrypted with AES-256-GCM before storage, the encryption key lives in the environment rather than the database, and dev-views has no code path that sends mail or modifies a domain.
What bounce rate should worry me?
Above 5% puts sending at risk — that is the threshold noted in the metric's own description in dev-views. For spam complaints the number is much lower: mailbox providers generally expect complaint rate under 0.3%. Both are tracked as rates rather than raw counts precisely so the threshold means something regardless of your volume.
Are the rates calculated by dev-views?
No, they come from Resend's metrics endpoint directly. Resend knows which denominator each rate uses, and recomputing them from the raw counts would quietly disagree with the figures shown in their own dashboard — which is worse than not showing them.
Why are opens and clicks empty?
Open tracking and click tracking are per-domain settings in Resend, and both are off unless you enable them. The domain group shows the current state of each, so a blank engagement tile has a visible explanation rather than looking like zero engagement.
Works alongside
dev-views is most useful when more than one service is on the board. These are the ones people connect next to Resend.
Watch Resend alongside the rest of your stack
One read-only surface for every service you run. Join the waitlist for early access.