Transactional email, incidents, and notifications.
Transactional email
GetRatchet uses Resend for account and operational email. Set RESEND_API_KEY and EMAIL_FROM (for example GetRatchet <notify@your-verified-domain.example>) in the server environment. Verify the sender domain in Resend and publish the DNS records it requests before enabling production delivery. Never expose the API key to the browser. Production deploys without these variables remain available, but sends report Email provider is not configured and account verification cannot complete.
lib/email.ts centralizes sending and branded HTML/plain-text templates. The development-only /email-preview page displays sample messages without sending them. Account messages contain short-lived links and security advice. Operational templates contain only organization, service/project context, a short summary, and an internal details link. Never include API credentials, agent inputs, outputs, prompts, full errors, or signed URLs in an email.
The sender should have working DKIM and SPF records, a suitable DMARC policy, and a monitored reply address. Test delivery to major mailbox providers after the domain and key are configured. Provider errors are reduced to status codes in application responses; do not log response bodies, request headers, or full recipient addresses. Alert failures must be handled outside the execution transaction.
Operational incidents
The Incidents page keeps versioned records for worker absence, circuit openings and recoveries, exhausted steps, and completed recovery scheduling. Owners and admins choose event types and verified organization members as recipients. Alerts are disabled until configured. Every event remains in the organization history even if email is disabled, grouped, or fails. Repeat events for the same target within ten minutes are grouped for email; the history still records each event.
Email is attempted after the execution transaction commits. A failed send cannot change the tool result. Failed sends retry on later worker polls, at most three attempts, with an increasing delay; the incident shows the final notification state. Delivery is at least once if a process stops after sending but before storing the receipt. Do not use these emails as an exact-count audit source.
Worker absence is detected when another worker in the same organization polls after its peer has missed five minutes of heartbeats. If every worker is offline, no worker poll can detect the outage; use an external uptime monitor for the GetRatchet worker fleet. The public status page reports platform availability separately from customer worker health.