Datadog can send email from Datadog through Volanea without a marketplace app or native plugin: configure an outgoing webhook, invoke it from a monitor notification, and have that webhook post a Volanea email request. This pattern is useful when you need alert emails to come from your own verified sending domain, follow your application’s email controls, or reach recipients who are not Datadog users.

The important constraint is architectural: Datadog is the event source, while Volanea is the email delivery API. A Datadog monitor changes state, Datadog renders a webhook payload, and the webhook request becomes an API request that creates an email. That is a direct HTTP integration, not an installed Datadog integration.

What starts the email in Datadog

The concrete trigger is a Datadog monitor notification. A monitor evaluates a query on a schedule or as data arrives; when its alert state changes or meets the configured notification conditions, Datadog sends the monitor notification. Adding an @webhook-name mention to the monitor message tells Datadog to deliver that notification to the outgoing webhook associated with that name.

This distinction matters. A log line, trace, metric, or incident does not independently call Volanea. It must first be evaluated by a monitor (or otherwise be routed into a Datadog notification flow) that emits the @webhook-name mention. The useful event boundary is therefore the monitor notification, including its title, body, alert status, scope, tags, and links.

A typical alert lifecycle looks like this:

A metric, log, Synthetic test, or other signal violates the monitor’s query and threshold.
Datadog changes the monitor’s state, for example from OK to Alert.
Datadog renders the monitor’s message template and sees the webhook mention.
Datadog sends an HTTP POST to the configured outgoing-webhook URL.
Volanea accepts the REST request and queues the resulting email for delivery.
When the monitor recovers, a recovery notification can send a separate email if the message includes the same webhook mention.

For operations teams, that gives one clear source of truth: the monitor determines whether an email should exist. Do not build an additional polling process that scans every alert and sends another email; it is much harder to deduplicate and reason about than a notification-driven design.

Why use an outgoing webhook rather than a native app

Volanea does not provide a native Datadog app, Marketplace listing, or one-click Datadog plugin. The supported route is Datadog’s webhook integration: it sends a POST request to an endpoint you configure and can render Datadog notification variables into a custom payload.

That is not a limitation for most alert-email use cases. An outgoing webhook is often preferable because it makes the mapping explicit. You can decide which state changes deserve email, which message fields become the subject, whether to send plain text or HTML, and whether an alert should go to a fixed operational list or a routing service.

It also avoids treating Datadog as an email-template editor. Datadog should describe the operational event; Volanea should deliver the message. If you need recipient lookup, escalation policies, localization, approval, or a rich branded template, place a small authenticated service between the two systems rather than trying to encode business logic in a monitor message.

Configure the Datadog webhook endpoint

Create an outgoing webhook integration in Datadog and assign it a memorable webhook name, such as volanea-alerts. Configure its URL as the Volanea email-send endpoint and configure the request as JSON. Then add @webhook-volanea-alerts to the monitor message that should create email.

The exact monitor text can remain useful to Datadog users while the webhook receives a purpose-built email payload. For example, a monitor message might include the investigation link, runbook, and a notification mention:

{{#is_alert}}
Checkout error rate is above 5% for five minutes.
Investigate: https://runbooks.example.com/checkout-errors
@webhook-volanea-alerts
{{/is_alert}}

{{#is_recovery}}
Checkout error rate has returned below 5%.
@webhook-volanea-alerts
{{/is_recovery}}

Use Datadog’s conditional notification variables deliberately. If the webhook mention is outside those conditionals, Datadog can notify on states you did not intend to email about. For noisy monitors, send only alert and recovery messages, or send only the escalation state that is meaningful to the recipient.

Before enabling a production monitor, test the webhook with a non-production recipient. Validate the monitor’s rendered notification, not merely the static JSON template. Variables can be empty for particular monitor types, and a body that looks correct in an editor can produce an unhelpful email after an actual alert.

Map the Datadog payload to a Volanea email request

Datadog’s outgoing-webhook integration supports a custom JSON payload using notification variables such as $EVENT_TITLE, $TEXT_ONLY_MSG, $ALERT_STATUS, $TAGS, $LINK, $ALERT_ID, and $ALERT_SCOPE. The payload below maps those values directly to an email request.

Use the Volanea endpoint, authentication scheme, and field names documented in the email API reference and setup guides for your account. The example shows the complete mapping pattern: a stable sender and recipient are selected by your webhook configuration, while the subject and message body are derived from Datadog’s notification variables.

{
  "from": "Datadog Alerts <alerts@notify.example.com>",
  "to": ["oncall@example.com"],
  "subject": "[Datadog][$ALERT_STATUS] $EVENT_TITLE",
  "text": "$TEXT_ONLY_MSG\n\nStatus: $ALERT_STATUS\nScope: $ALERT_SCOPE\nTags: $TAGS\nMonitor: $LINK\nAlert ID: $ALERT_ID",
  "html": "<h2>Datadog alert: $ALERT_STATUS</h2><p><strong>$EVENT_TITLE</strong></p><p>$TEXT_ONLY_MSG</p><ul><li>Scope: $ALERT_SCOPE</li><li>Tags: $TAGS</li><li><a href=\"$LINK\">Open in Datadog</a></li><li>Alert ID: $ALERT_ID</li></ul>"
}

In the webhook configuration, the corresponding request is an HTTP POST to Volanea’s send endpoint with JSON content and the Volanea API credential supplied as an HTTP authorization header. Conceptually, the wire request is:

POST https://api.volanea.com/…send-endpoint-from-your-Volanea-docs…
Content-Type: application/json
Authorization: Bearer <VOLANEA_API_KEY>

{
  "from": "Datadog Alerts <alerts@notify.example.com>",
  "to": ["oncall@example.com"],
  "subject": "[Datadog][$ALERT_STATUS] $EVENT_TITLE",
  "text": "$TEXT_ONLY_MSG\n\nStatus: $ALERT_STATUS\nScope: $ALERT_SCOPE\nTags: $TAGS\nMonitor: $LINK\nAlert ID: $ALERT_ID",
  "html": "<h2>Datadog alert: $ALERT_STATUS</h2><p><strong>$EVENT_TITLE</strong></p><p>$TEXT_ONLY_MSG</p><p><a href=\"$LINK\">Open in Datadog</a></p>"
}

The JSON in the first block is the custom payload Datadog renders; the second block illustrates the resulting Volanea REST call. Do not copy an ellipsis as an endpoint. API URLs and authentication headers are security-sensitive integration details, so use the exact send URL and header syntax in your Volanea documentation rather than guessing from a generic HTTP example.

Treat alert text as untrusted content

The $TEXT_ONLY_MSG variable is appropriate for the text part. It is usually a safer choice than inserting a rich message directly into HTML because monitor text can contain characters that change HTML structure. If you include variables in an HTML part, encode or sanitize values in middleware when the content can include user-controlled text, log attributes, ticket titles, or tags.

For the simplest secure setup, send a rich text body plus a minimal HTML body that contains only values you control. A plain-text operational email is often easier to read on mobile and less likely to be damaged by unexpected markup.

Keep routing out of the payload when possible

A static to address is appropriate for a team inbox or on-call alias. Do not put individual addresses into monitor tags or log fields and interpolate them into the webhook payload. That turns telemetry into an email-recipient control plane and creates an avoidable risk of accidental or unauthorized external delivery.

When recipients depend on service, environment, or severity, send the webhook to middleware. Middleware can validate the Datadog request, map a known monitor ID to an approved recipient group, and then create the Volanea request with server-side credentials.

Protect the Volanea API key

For a direct webhook, the Volanea API key belongs in the outgoing webhook’s server-side authentication/header configuration in Datadog—not in the monitor message, JSON body, a dashboard widget, a public repository, or browser-side JavaScript. The webhook URL and header are configuration for a server-to-server request; they should be restricted to Datadog administrators and treated as production credentials.

Do not include the key as a query parameter. URLs commonly appear in browser histories, proxy logs, support screenshots, tracing systems, and audit records. An authorization header is materially better, but it is still a secret: do not paste it into monitor text, notification previews, tickets, or runbooks.

A direct Datadog-to-Volanea route is best for a narrow, fixed-purpose alert integration. Give the credential the least access available, use a key dedicated to Datadog alert sending, and rotate it when an administrator leaves or when the key may have been exposed. Ensure that the sender domain has been configured and authenticated in Volanea before alert traffic starts.

If your Datadog webhook settings cannot securely hold the required Volanea authentication header in your environment, do not weaken the design by embedding a key in the payload. Use a middleware endpoint instead. The middleware stores the Volanea API key in a server-side secret manager, while Datadog holds only a separate shared webhook secret or signed-request verification configuration.

Use middleware for routing, templates, and stronger controls

A small HTTPS endpoint is the more robust production pattern when alert emails need dynamic recipients, template rendering, ticket links, or central audit logging. Datadog posts its native notification payload to your endpoint. The endpoint verifies the request, checks the monitor and status against an allowlist, builds the Volanea email request, and returns a prompt success response.

This approach also separates two credentials. Datadog authenticates to your webhook endpoint using a dedicated inbound secret or other verification mechanism. Your service authenticates to Volanea using a key stored only in the server-side secret store. A compromise of the Datadog configuration does not automatically reveal the Volanea sending credential.

A practical middleware policy can include:

Allow only known Datadog monitor IDs and expected alert statuses.
Map each monitor to approved sender identities and recipient groups.
Strip or escape HTML from monitor text before building an HTML email.
Create a deterministic idempotency key from the monitor, alert transition, scope, and notification timestamp.
Record the Volanea message identifier alongside the Datadog alert identifier.
Return quickly after persisting work, then send asynchronously if enrichment can take time.

Middleware is also the right place to make a normal alert email useful. It can turn a raw threshold breach into a concise subject, add a runbook URL based on the monitor ID, insert a service owner, and distinguish a production customer-impacting page from a staging warning.

Design alert emails for deliverability and response

An alert email is transactional operational mail, not a campaign. Its value comes from speed, clarity, and trustworthy sender identity. Use a verified From domain that recipients recognize, such as alerts@notify.example.com, and avoid a no-reply address if recipients may need to escalate or forward the message.

The subject should expose the decision-making facts before the recipient opens the email. A useful structure is environment, severity, service, and state:

[PROD][ALERT] checkout-api error rate above 5%
[PROD][RECOVERY] checkout-api error rate normal

Include enough context in the body to begin investigation without requiring an immediate Datadog login: what happened, when, where, current state, affected scope, key tags, and a single authoritative link. Avoid attaching raw logs or large query results. Besides making the message difficult to scan, that can leak sensitive data and increase the chance that email filtering delays the notification.

For addresses that are typed or imported into a routing list, validate them before production rollout with the email address verification tool. Address quality does not replace alert routing governance, but it can prevent a failed notification caused by a typo in an escalation alias or external contact.

When this breaks

Every integration has two hops: Datadog must successfully deliver the webhook, and Volanea must accept and process the resulting email request. Troubleshoot them separately. A Datadog notification record does not prove Volanea accepted a message, and an accepted message does not prove the monitor condition was correctly configured.

Datadog retries can create duplicate emails

A webhook delivery can time out or receive a transient error after Volanea has already accepted the email. Datadog may retry the outgoing webhook, which can create a second email unless the receiving endpoint or API request is idempotent.

For direct sending, duplicate prevention options are limited by the webhook and API capabilities available to you. For important alerts, middleware is safer: derive an idempotency key from a stable combination such as alert_id, alert_transition, alert_scope, and the notification timestamp. Store that key before sending, and return the original successful result when a retry arrives.

Do not deduplicate solely on subject line. Two genuine incidents can share a title, and a recovery message may intentionally use the same service name. Include monitor identity, state transition, and scope in the deduplication decision.

Webhook timeouts and slow processing

Datadog expects an outbound webhook endpoint to respond promptly. If your endpoint performs recipient lookups, template fetches, incident creation, or multiple API calls before responding, it can time out and trigger retries. Make the synchronous path small: authenticate, validate, persist the event, enqueue it, and acknowledge it.

If you send directly to Volanea, keep the request body compact and avoid remote dependencies in the notification path. If Volanea returns a non-success response, inspect the response code and request identifier in your delivery logs before retrying manually. Repeatedly replaying an alert without idempotency controls is a common source of notification storms.

Missing fields and empty variables

Datadog notification variables are not universally populated in every context. A variable that exists for one monitor type, alert status, or notification source may render empty for another. The result can be a blank subject suffix, a missing link, or a body with incomplete scope information.

Build a test matrix that includes alert, warning, recovery, no-data, and any renotification state you use. Test every monitor family that shares the webhook: metric, log, Synthetic, and composite monitors can expose different context. In middleware, treat missing optional fields as expected input and provide defaults rather than failing the entire send.

Authentication and sender failures

A 401 or 403 response usually indicates an invalid, expired, revoked, or incorrectly placed Volanea credential. A sender-related error usually means the From address or domain is not authorized. Keep those failures distinct in alerts and logs; changing the monitor does not fix an unverified sender, and rotating an API key does not fix a malformed JSON payload.

Also check whether a corporate proxy, egress rule, or URL allowlist prevents Datadog from reaching the endpoint. For middleware, require HTTPS and make the endpoint publicly reachable only to the extent necessary for Datadog delivery, then add request verification and network controls where supported.

Observe the integration like a production service

The integration itself needs monitoring. Create a dashboard or log view for webhook attempts, accepted sends, rejected sends, latency, retries, and deduplicated events. If you use middleware, emit structured logs containing the Datadog monitor ID, alert status, scope, event timestamp, idempotency key, and Volanea response or message identifier—but never the API key or full secret header.

Set an internal alert for sustained delivery failures. This may feel recursive, but it protects a critical blind spot: the system that is supposed to tell people about failures can fail silently. Route that integration-health alert through a different channel, such as a separate chat or paging path, so it does not depend entirely on the same email flow.

Review volume after launch. A monitor with a short evaluation window, flapping threshold, or broad group-by can create many notifications. Email delivery may be working perfectly while the alert policy is operationally wrong. Use Datadog recovery thresholds, delays, renotification settings, and grouping deliberately before increasing email throughput.

A practical rollout checklist

Start with one low-risk monitor and a mailbox owned by the implementation team. Verify each boundary, then expand to production service alerts and shared on-call aliases.

Confirm the Volanea sender domain and From address are authorized.
Create a dedicated Volanea key for this integration and protect it in Datadog’s server-side webhook configuration or a secret manager.
Configure a JSON outgoing webhook and give it an unambiguous name.
Add the @webhook-name mention only to the monitor states that should produce email.
Test alert and recovery notifications with realistic monitor data.
Check the rendered subject, body, Datadog link, alert status, tags, and scope.
Verify Volanea acceptance and delivery events for the test recipient.
Add deduplication and request logging before connecting high-volume or paging-critical monitors.
Document the owner, key-rotation process, recipient policy, and rollback procedure.

The rollback is simple: remove the webhook mention from the monitor message or disable the outgoing webhook while retaining the monitor. That stops the email route without deleting the detection logic. Keep a record of the previous configuration so that a temporary disablement does not become a permanent loss of notifications.

Conclusion

To send email from Datadog with Volanea, use Datadog’s monitor notification as the trigger and an outgoing webhook as the transport. The monitor state change initiates the send; Datadog variables provide the alert context; Volanea delivers the resulting operational email from your verified domain.

A direct webhook is suitable for fixed recipients and a simple alert payload. Move to middleware when you need recipient routing, sanitization, audit trails, robust idempotency, or stronger credential isolation. In both designs, test every notification state, keep the API key out of client-visible content, and treat duplicate prevention as a first-class reliability requirement.

FAQ

Does Volanea have a native Datadog integration?

No. Volanea does not ship a native Datadog app, Marketplace listing, or plugin. Use Datadog’s outgoing webhook capability to call Volanea’s REST email API, optionally through middleware.

What Datadog event triggers the email?

The trigger is a Datadog monitor notification. When the monitor enters a configured notification state, its message invokes the outgoing webhook through an @webhook-name mention.

Can Datadog send directly to the Volanea API?

Yes, when the outgoing webhook can safely provide the required HTTP authentication and JSON payload. Use middleware instead when routing, idempotency, secret isolation, or transformation requirements are more complex.

How can I stop duplicate alert emails?

Expect retries after timeouts or transient failures. Use middleware to persist a deterministic idempotency key based on alert identity, transition, scope, and time before creating the Volanea email request.

Should the Volanea API key be in the monitor message?

No. Never place an API key in monitor text, JSON payload content, source code, or client-visible configuration. Store it only in protected server-side webhook authentication settings or a server-side secret manager.

How to Send Email from Datadog with Volanea