StrataDocs

Agent notifications

Agent notifications email you after a run finishes — either every time, or only when something goes wrong — so you can review the output (or the failure) without having to open Strata and check the run history.

Turn notifications on

Open the agent's wizard (deploy a new agent, or click an existing agent then Details) and advance to Step 6 — Notifications.

  1. Toggle Email me when this agent runs on. The configuration block expands.
  2. Choose When to email:
    • After every run — success or failure, you always get the email.
    • Only on failures — quieter; the agent only emails you when the run ends in error or timeout.
  3. Fill in recipients:
    • Send to — defaults to your connected Outlook mailbox if Outlook is connected; otherwise type any email address.
    • CC — comma-separated list of additional recipients (optional).
    • BCC — comma-separated list (optional).
  4. Optionally customize the Subject template and Message template (see placeholders below).
  5. Toggle Include the run output in the email off if you only want the status and not the agent's full output.
  6. Click Continue through any remaining steps, then Deploy agent / Save changes.

Who the email comes from

Notifications are sent by Strata's transactional sender (backed by Azure Communication Services) — not from your own Outlook mailbox. This is deliberate:

  • The email arrives as a clean "Strata notification" instead of a self-addressed "note to self" cluttering your sent folder.
  • Agent notifications work even when Outlook isn't connected, as long as Strata can resolve your account's email address.

The from address is fixed at the Strata deployment level (the AZURE_COMM_SENDER environment variable) — there is no per-org sender override in the admin console. See /docs/admin/notification-templates for the full rundown, including SPF/DKIM/DMARC tips for tenants that quarantine third-party senders.

Subject and body templates

Both Subject template (200 char max) and Message template (4,000 char max) support placeholder substitution. Available placeholders:

PlaceholderResolves to
{agent.name}The agent's name.
{agent.id}The agent's UUID.
{status}finished successfully, timed out, or failed.
{elapsed}Run duration in seconds (e.g. 12.3s).
{output}The agent's output, truncated to 12,000 characters.
{error}The error message (empty on success).

Placeholders are case-insensitive — {STATUS} and {Status} resolve too.

Leave Subject template blank to get the default subject:

  • Success: Your <agent name> report is ready
  • Failure or timeout: Agent <agent name> couldn't finish its run
Note

Throttled runs (rate-limited or hit a transient AI outage) do not send a notification email at all. A throttled run with a cron schedule defers ~15 minutes and re-fires, so a "problem" email would contradict the retry.

Leave Message template blank to get the default body, which:

  • On success: includes the agent's output if Include the run output in the email is on, or a single sentence "The agent run completed successfully" if it's off.
  • On failure: a styled PROBLEM banner with the error text, optionally followed by any partial output.

Where the output comes from

Agents emit free-form Markdown that's converted to HTML for the email body. Strata's agent system prompt enforces email- and inbox-friendly formatting:

  • Use clean structure — headers, **bold**, bullet/numbered lists, block quotes, and Markdown pipe tables for any rows-by-columns data.
  • Charts are allowed: an agent may emit a single `chart fenced block (a Chart.js config). It renders as a real interactive graph in the Inbox and run history. Email can't run Chart.js, so the email swaps the chart for a short "Chart is shown in the Strata inbox" note — the agent is told to always restate the key figures in text or a table so no data is lost in the email.
  • No callout syntax (> [INFO], > [WARN], etc.) — these are stripped, since they read as raw text outside chat.
  • No inline color tags ([red:...], [green:...]) — these are chat-only and would appear literally, so they're stripped. For status emphasis the agent uses inline HTML instead (<span style="color:#15803d">on track</span>), which renders correctly in the Inbox.
  • No other fenced rich blocks ( `excel , `pdf , `table , `kpi , etc.) — those render only inside the chat UI and show as raw code here. The agent uses a Markdown table or plain text instead.
  • Email subjects emitted in tasks involving emails are rendered as Markdown links so the recipient can click straight through to the message in Outlook.

If you ask the agent to "generate an Excel and attach it to the email", Strata sends a separate email through your connected Outlook account for the actual outbound message — the notification is just the run summary.

Why use errors-only mode

Errors-only is the safety pattern for agents that don't need a daily heartbeat. The SQL anomaly watcher built-in template uses errors-only by default: it runs hourly, finds nothing wrong 99% of the time, and emails you only when something looks off. You stay quiet and trust the silence.

Use After every run when:

  • The run output is the actual product (daily briefing, weekly digest).
  • You want explicit confirmation the job ran.

Use Only on failures when:

  • The agent is a monitor or watcher.
  • The output is normally empty (no anomalies found, inbox clean, no new files).
  • You don't want to train yourself to ignore the inbox.

In your inbox

Completed agent runs also surface inside Strata, independent of email. When an agent finishes, a notification appears in your Inbox (the Inbox tab in the sidebar) with the run's status and a summary of its output. Unread agent notifications show a count badge on the tab; opening one marks it read. Read agent run notifications move to the archive after 90 days rather than disappearing immediately — the Inbox active list shows only unread items, while the archive retains everything. See Inbox for the full breakdown of message types and retention.

This in-app notification does not depend on the email toggle in Step 6 — use email when you want the result pushed to a mailbox, and rely on the Inbox when you just want to glance at recent runs inside Strata.

Testing your notification

Click Run now from the agent's detail page to trigger a real run. If notifications are enabled, you should receive the email within a few seconds of the run finishing. Notifications are also sent for runs triggered by the scheduler and by webhooks; they are not sent for dry runs.

What can go wrong

  • email_to must be a valid email — the Send to field didn't pass the email regex. Check for typos.
  • email_cc contains invalid email "<value>" (or the same for email_bcc) — one of the comma-separated entries didn't validate. Fix or remove it.
  • No email arrived after a run — verify the agent's notifications are enabled (the toggle in Step 6 is on) and the run actually triggered a notification (success runs in errors-only mode don't). Check your spam folder; ACS-backed senders sometimes land there on the first delivery.
  • Email arrived in spam / quarantined — your tenant's SPF/DKIM/DMARC policy may be stricter than the Strata sender's alignment. See the admin notification-templates page for the recommended allow-list and DMARC configuration.
  • Output looks like garbled markdown — the agent emitted a chat-only rich block ( `excel , `pdf , `table , etc.) that doesn't render here. A `chart block is fine and renders in the Inbox. Tighten the prompt to ask for a Markdown table or plain prose, or remove the corresponding capability.
  • The notification subject contains literal {agent.name} — your template misspells a placeholder. Check the spelling and the braces; placeholders are case-insensitive but must use the exact names listed above.

Related