Daily email deliverability digest in Slack

Build me a code workflow that posts a daily email deliverability digest from Postmark into a Slack channel, Monday through Friday at 9am local time.

Trigger: cron, weekdays at 09:00 in the user's timezone.

Inputs the user should configure at the top of the workflow: the Postmark server to monitor (default to their production server), the Slack channel to post to (default #email-ops), the timezone, and the green/yellow/red thresholds. Defaults: red when hard-bounce rate is above 2 percent OR there are any spam complaints in the window; yellow when the soft-bounce rate is more than 50 percent above its 7-day average; green otherwise.

Steps:

1. Sanity check the Postmark server. Call Postmark's Get Server endpoint and confirm DeliveryType is "Live" (not "Sandbox"). If it is a sandbox server, post a single-line warning to Slack and exit, so we never silently report on test traffic.

2. Pull yesterday's stats from Postmark, for the 24-hour window ending at midnight local time. Use these three operations in parallel, each scoped to the configured server and to the [fromdate, todate] range that covers yesterday:

- Postmark Get Outbound Overview (sends, bounce rate, opens, unique opens, spam complaints, total clicks).

- Postmark Get Bounce Counts (daily and total counts by type: HardBounce, SoftBounce, Transient, SMTPApiError). Bounce rate is (HardBounce + SoftBounce) / Sent.

- Postmark Get Spam Complaints (per-day and total spam complaints).

All three endpoints return the whole window in one call; no pagination needed.

3. Pull the previous day's stats (the day before yesterday) using the same three operations, so we can compute day-over-day deltas.

4. Pull the prior 7 days of stats using the same three operations with a 7-day window ending the day before yesterday, and compute 7-day averages for: total sends, hard bounces, soft bounces, bounce rate, spam complaints, unique opens. This is the baseline.

5. Decide the status. Apply the threshold rules in order: red first, then yellow, then green. Capture the reason string for the status (e.g. "hard-bounce rate 2.4% > 2% threshold") so we can show it in the message.

6. Format a compact Slack message. Use Slack mrkdwn, not standard Markdown. It should have: a one-line headline with a colored circle emoji matching the status (🟢/🟡/🔴), the date the digest covers, and the reason if not green. Below that, a small fixed-width table inside a code block with columns Metric | Yesterday | Δ vs prior day | 7-day avg, with rows for Total Sends, Hard Bounces, Soft Bounces, Bounce Rate, Spam Complaints, Unique Opens. Format percentages to one decimal place. End with a single line linking to the Postmark server activity page for that server, formatted as <https://account.postmarkapp.com/servers/{serverId}/streams/outbound/activity|Open in Postmark>.

7. Post the message to the configured Slack channel using Slack Send a Message.

Edge cases to handle:

- If yesterday had zero sends, skip the threshold logic and post a single calm line: "No sends in the last 24 hours on {serverName}." Do not flag this as red.

- If any of the Postmark calls fails, post a short failure notice to Slack with the error code/message and the server name, so the team notices the digest didn't run cleanly.

- Round all rates to one decimal place. Show counts as integers with thousands separators.

This is deterministic arithmetic and formatting on structured stats data, so build it as a code workflow with discrete nodes, not an agent.

Additional information

What does this prompt do?

Posts a short summary of yesterday's email performance to a Slack channel of your choice every weekday at 9am.
Calls out bounce rate, hard bounces, spam complaints, total sends, and unique opens, with day-over-day changes and a 7-day running average for context.
Tags the digest green, yellow, or red so the team knows at a glance whether to investigate.
Includes a deep link to your Postmark server activity page so anyone can click in and dig further.

What do I need to use this?

A Postmark account, and the server you want to monitor (usually your production server).
A Slack workspace and permission to post in the channel you want the digest to land in, like #email-ops.

How can I customize it?

Change the time it runs, or the days of the week it covers (you might want weekends too).
Point it at a different Slack channel, or post to a private one only the on-call sees.
Adjust the thresholds that flip the status to yellow or red, like the hard-bounce rate or the spam complaint count.
Swap in a different Postmark server if you run separate production and marketing servers.

Frequently asked questions

Will this catch a sender reputation problem before it actually hurts deliverability?

That is the point. By the time mailbox providers start throttling you, hard bounces and spam complaints have usually been creeping up for days. A daily snapshot with a 7-day baseline surfaces those trends early so you can pause a list, fix a list import, or kill a campaign before it starts costing you inbox placement.

Can I monitor more than one Postmark server?

Yes. The cleanest pattern is one digest per server, so production, marketing, and lifecycle each get their own daily message. Duplicate the workflow, point each copy at a different server, and post each to its own Slack channel.

How do I change the thresholds that flip the status to yellow or red?

The thresholds are exposed as inputs at the top of the workflow. By default red triggers when the hard-bounce rate is above 2 percent or any spam complaints are recorded, and yellow triggers when soft bounces are running well above their 7-day average. You can edit either of those numbers in the workflow editor without touching any code.

What if there were no sends yesterday?

The digest still posts, but with a calm "no sends in the last 24 hours" line instead of a red flag. That way the team can tell the difference between a quiet day and a workflow that silently broke.

Can I send the digest somewhere other than Slack?

Yes. The reporting step is separate from the formatting step, so you can swap Slack for email or another chat tool. The deliverability math and the status logic stay the same.