ErrLens

Appearance

Email ​

ErrLens sends email alerts via your own SMTP server rather than a shared transactional relay. Two reasons:

  1. Deliverability. The From address matches your domain; your DKIM, SPF, and DMARC policies apply. Mail lands in inboxes instead of spam.
  2. Privacy. Issue titles and culprit strings can contain hints about internal code paths. We'd rather your tenant's SMTP server see that than ours.

Trade-off: email is the only alert kind that requires per-tenant config. The webhook kinds are zero-config beyond pasting a URL.

What it looks like ​

Each delivery becomes one multipart/alternative email:

  • Subject — New issue in <project>: <title> (or the frequency variant)
  • HTML body — level-coloured strip on the left, project + level + times-seen meta, FactSet-style rows for culprit / environment / release, an Open in ErrLens button
  • Text body — same content, plain text, for clients that strip HTML

From: uses the address you configure under SMTP. To: is the destination's recipients list.

Configure SMTP (once per organisation) ​

  1. Open Org alerts.
  2. Find the SMTP card.
  3. Fill in:
    • Host — e.g. smtp.fastmail.com, smtp.office365.com, smtp-relay.gmail.com, email-smtp.eu-west-1.amazonaws.com
    • Port — usually 587 (STARTTLS) or 465 (implicit TLS). ErrLens picks the right transport based on the port.
    • Username — typically your full mailbox address
    • Password — encrypted at rest with AES-256-GCM keyed by SMTP_ENC_KEY. ErrLens never logs the plaintext.
    • From address — the email the message claims to come from. Must pass your SMTP provider's "allowed sender" policy.
    • Use TLS — leave on unless your relay only speaks plaintext on an internal network.
  4. Save SMTP.

If you ever rotate the password, paste the new one and save again. Leaving the password blank when editing keeps the existing value (so you can update the From address without re-typing creds).

Add an email destination ​

  1. Still on Org alerts (or a project's Alerts tab).
  2. Add destination → pick Email.
  3. Name — On-call ops, Frontend team digest, whatever's recognisable in the list.
  4. Recipients — comma, semicolon, or newline-separated list of email addresses. There's no "unsubscribe" link on alerts; pick a list you actively want.
  5. Save → Send test event. A test email should land within a few seconds.

Quirks ​

  • One SMTP config per organisation. Multiple email destinations share the same SMTP server. If you need to send through two providers (e.g. internal vs external alerts), set up an n8n destination instead and split inside the workflow.
  • No retries on hard SMTP errors. A 5xx SMTP response (bad mailbox, auth failed) shows up on the destination's consecutive failures counter. The dispatcher retries 4xx transient errors a few times then gives up.
  • Implicit TLS on port 465. The web UI's TLS toggle is informational for ports other than 465 — STARTTLS is used whenever the server advertises it. On 465 the connection is encrypted from the first byte.

Troubleshooting ​

  • Test event errors with "auth failed": the password didn't decrypt cleanly or the SMTP server rejected it. Re-save the password.
  • Test event errors with "no SMTP config for organisation": you added an email destination before saving the SMTP card. Save SMTP first.
  • Test event succeeds but email never arrives: check your provider's outbound logs. Many transactional relays silently drop mail with a From address that doesn't match a verified sender.
  • SMTP_ENC_KEY is not configured: the ingest service or the web service doesn't have the env var set. They both need the same value. See the deployment docs.