Use email alert sources when a monitoring tool, script, or workflow can send email but doesn’t support webhooks. Emails sent to the source’s unique address can be used to create alerts in incident.io.Documentation Index
Fetch the complete documentation index at: https://docs.incident.io/llms.txt
Use this file to discover all available pages before exploring further.
Creating an email alert source
When you create an email source, incident.io generates a unique inbound address like the one below:Example email address
- Synthetic monitors, cron jobs, or legacy scripts that only emit email
- Customer support or internal escalations where critical emails should trigger alerts
Default behavior
Without advanced email parsing, email sources work in standard mode:- The subject becomes the alert title and the body becomes the description
- Each email creates a new alert (no deduplication)
- Alerts stay in
Firingindefinitely and need manually resolving
Advanced email parsing
Enable Advanced email parsing in the alert source’s connection manager to write a transform expression — JavaScript that extracts structured data from incoming emails. Use this when you want to:- Deduplicate alerts so the same issue doesn’t create multiple alerts
- Mark alerts as resolved based on subject or body patterns
- Pull team, severity, or service information into alert attributes
$.
Example payload
Your transform expression
Available fields on $
| Field | Description |
|---|---|
to | The inbound address that received the email |
from | The sender address from the email headers |
subject | The email subject line |
text | Plain text body |
html | HTML body — prefer text for transforms unless you need to parse markup |
header_message_id | The Message-ID header — useful as a deduplication key |
envelope.from | SMTP envelope sender |
envelope.to | Array of SMTP envelope recipients |
Return schema
| Property | Description |
|---|---|
title | The title, or name, of the alert |
status | firing or resolved — derive from email content |
description | An optional long-text description, rendered alongside the title |
source_url | An optional link to the origin of the alert |
deduplication_key | Used to deduplicate alerts. Returned in the object — not configured separately |
metadata | An unstructured object for attributes like team, service, or severity |
Expressions that take longer than 25 milliseconds to execute will result in a default alert being created. Plain
JavaScript expressions normally execute in well under a millisecond.
FAQs
What happens if there's an error in the JavaScript?
What happens if there's an error in the JavaScript?
If we hit an error running the transform expression, we’ll create a default alert with the whole payload accessible on a
source_payload property when inspecting the alert.How do I resolve email alerts?
How do I resolve email alerts?
Emails don’t have a built-in concept of resolution. Either derive status from the subject or body in your transform
expression (e.g. resolve when the subject starts with
[RESOLVED]), or enable
auto-resolve on the source so alerts time out after a set duration.What if I don't return a deduplication key?
What if I don't return a deduplication key?
We’ll use the message ID from the email headers. The
header_message_id is a stable per-email identifier; for
repeated alerts about the same underlying issue we’d recommend using transform expressions to derive a key from the
subject or a structured field in the body.Can I parse HTML emails?
Can I parse HTML emails?
Yes —
$.html is available, but reliably parsing HTML inside a 25ms transform is hard. Most monitoring tools include a plain text alternative in $.text. Prefer that when possible.