Design alerting for your outbound infrastructure before it burns
Designs a complete monitoring layer for sending infrastructure: a per-domain metric catalog, volume-tuned warning and critical thresholds, check cadences with the tool that runs each, anti-fatigue alert routing, runbooks for the five likeliest incidents, and a weekly drift digest. Problems surface in hours instead of after a burned domain.
You are an outbound infrastructure engineer who has managed sending across hundreds of domains and inboxes, and you know the brutal asymmetry: deliverability problems compound for days before anyone notices, but the evidence was in the metrics from hour one. Nobody watches dashboards; alerts have to come to you, with thresholds set before trouble, not during it. Design the alerting and monitoring layer for my outbound infrastructure. Output: 1. METRIC CATALOG — everything watched, per inbox and per domain: bounce rate, spam complaint rate, reply rate trend, open tracking anomalies (where still measurable), sending volume versus plan, blacklist status, DNS record health (SPF, DKIM, DMARC still valid), and warmup status for young inboxes. 2. THRESHOLDS — for each metric: a warning level and a critical level with the reasoning, tuned to my volume (a 3% bounce rate means different things at 50 sends and 5,000). 3. CHECK CADENCE — which metrics check hourly, daily, weekly, and what tool or workflow performs each check (sequencer webhooks, n8n scheduled jobs, a blacklist API). 4. ALERT ROUTING — where each severity lands (Slack channel, email, phone for critical), and the anti-fatigue rules: deduplication windows, quiet-hours policy for warnings, never for criticals. 5. RUNBOOKS — for the five most likely alerts: first three diagnostic steps and the immediate mitigation (pause inbox, pull domain from rotation, cut volume 50%). 6. WEEKLY DIGEST — the five-number summary a human reviews even when nothing alerted, because drift hides below thresholds. Rules: every alert must name its runbook — an alert without a next action is just anxiety. Absence alerts are mandatory: zero events is itself an event. Before designing, interview me. Ask ONE AT A TIME, waiting for my answer each time: 1. How many domains and inboxes, and what daily volume across them? 2. What sequencer and infrastructure tools do you run? 3. What monitoring exists today, if any, and what incident hurt you most recently? 4. Who should be woken for a critical alert, and where does the team live (Slack, email)? 5. What automation platform can run scheduled checks (n8n, Make, none)? Then produce the full design with runbooks.
How to use it
- 1
Copy the prompt into Claude, ChatGPT, or any LLM.
- 2
Answer the interview with real volumes per domain — thresholds only work when tuned to actual scale.
- 3
Build the scheduled checks in n8n (or your platform) starting with bounce rate and blacklist checks — the two fastest killers.
- 4
Print the runbooks into your ops docs, and rehearse the pause-inbox mitigation once so it's muscle memory.
Best practices
Alert on absence aggressively: a webhook that stops firing looks identical to a great day with no problems.
Resist adding metrics without runbooks; every unactionable alert erodes trust in the actionable ones.
Review threshold hit rates monthly — thresholds that never fire are set wrong in one direction, ones firing daily in the other.
When a critical fires, cut volume first and diagnose second; sending through an incident deepens the damage.
Example: what this looks like in practice
A RevOps lead at a 40-person agency-style consultancy runs 12 domains and 36 inboxes through Smartlead at 2,800 sends a day, with monitoring consisting of 'we look at replies'. Last quarter a blacklisted domain sent for nine days before anyone noticed. The design returns a metric catalog checked via Smartlead webhooks and an n8n scheduled job hitting a blacklist API daily, thresholds like bounce warning at 2% and critical at 4% per inbox, criticals routed to a phone-notifying Slack channel, and runbooks whose first mitigation is always removing the affected inbox from rotation. Week two, the DNS check catches a DKIM record broken by a registrar migration within four hours — an incident that previously would have quietly halved deliverability for a month.
Best fit
This prompt is one gear in a bigger machine. We orchestrate 20+ tools into outbound systems our clients own — and guarantee the results.
Apply for a Pilot Spot → →Frequently asked questions
Per inbox and per domain: bounce rate, spam complaint rate, reply-rate trend, sending volume versus plan, blacklist presence, and DNS record validity (SPF, DKIM, DMARC). Reply-rate trend is the most underrated — a 40% week-over-week drop with stable volume is often the first visible symptom of placement problems.
More automation & workflow design prompts
Build a system prompt for an AI cold email reply agent
Interviews you about your offer, booking flow, and voice, then generates a complete production system prompt for an AI reply agent — classification taxonomy, response rules, escalation conditions, and a strict JSON output contract an n8n or Zapier workflow can parse. You get the artifact teams pay thousands to have written, tuned to how you actually talk.
Turn a manual sales process into an automation blueprint
Converts a fuzzy 'we do this by hand every week' description into a structured blueprint with a detectable trigger, labeled steps, edge cases, human checkpoints, and failure alerts. It forces the design decisions people usually discover mid-build, so what you hand to n8n, Zapier, or an ops hire is assembly work, not archaeology.
Architect a Clay table before you burn the credits
Designs the Clay table before you build it: sources, column order, run conditions, waterfalls, outputs, and a credit estimate. Column ordering and gating are where most teams silently overspend, so the prompt enforces filter-first architecture and makes every paid column defend its run condition — typically cutting credit burn 40-70% versus enrich-everything builds.