Skip to content

Platform
Platform overviewThe operating model, end to end ArchitectureTopology, boundaries and blast radius Workflow orchestrationScripts, AI goals and approvals in one DAG GitOps configurationReviewable, promotable platform intent Governance and AAADefault-deny, caller-scoped decisions AI and MCPApproved models, tools, context and limits Knowledge and contextThe policies and guardrails you bind to a step Runtime and executionDocker and Kubernetes placement Evidence and monitoringDurable proof attached to the run
Use cases
All use casesTen workflows shown as governed runs Production incidentDiagnose and roll back behind an approval gate Release preparationScope, gates, notes and change request Hotfix to productionOne trail from complaint to emergency change Security scan triageFindings to scoped, tracked fixes
Why NopsAI
Integrations
Security
Resources
All resourcesDefinitions, comparisons and evaluation checklists AI agent governanceBoundaries that survive production MCP governanceFour decisions before a tool is available MCP securityControls when a server can reach production Self-hosted platformsThe evaluation checklist a security review uses
Pricing

Docs Book a demo

Notifications

Team-routed mail notifications for run outcomes, approvals, and alerts.

How-toAdministratorOperator

Key points

SMTP settings live in setting/system/mail.yaml and are managed through /v1/system/notifications/mail.
POST /v1/system/notifications/mail/test sends a test message so delivery can be verified before an incident depends on it.
Notification routes are owned per team through /v1/teams/{teamID}/notifications.
Run notification lineage follows run_team_path, which is why schedules and external triggers set it.
Branding is controlled by NOPSAI_MAIL_LOGO_URL, NOPSAI_MAIL_WEBSITE_URL, NOPSAI_MAIL_SUPPORT_URL, and NOPSAI_MAIL_FOOTER_ADDRESS.

Before you start

Mail settings: SMTP settings configured for the platformcurl -s -H "Authorization: Bearer $NOPSAI_TOKEN" "$NOPSAI_URL/v1/system/notifications/mail" | jq
Team: The team ID that should receive notifications

Steps

01
Configure delivery once, at the platform level
Mail settings are a system concern. Teams choose what they are told about, not how it is delivered.
Read and update mail settingsbash
```
curl -s -H "Authorization: Bearer $NOPSAI_TOKEN" "$NOPSAI_URL/v1/system/notifications/mail" | jq
curl -sX PUT "$NOPSAI_URL/v1/system/notifications/mail" \
  -H "Authorization: Bearer $NOPSAI_TOKEN" \
  -H "Content-Type: application/json" \
  --data @mail-settings.json
```
Replace before running
mail-settings.json carries the SMTP host, port, credentials reference, and sender address.
02
Send a test before trusting it
The test route exercises the real delivery path, which is the only way to know the credentials and sender are accepted.
Send a test messagebash
```
curl -sX POST "$NOPSAI_URL/v1/system/notifications/mail/test" -H "Authorization: Bearer $NOPSAI_TOKEN" | jq
```
Verify
- The test message arrives, or the response names the delivery failure.
03
Subscribe the team
Notification settings hang off the team, so ownership decides who hears about a run.
Read team notificationsbash
```
curl -s -H "Authorization: Bearer $NOPSAI_TOKEN" "$NOPSAI_URL/v1/teams/$TEAM_ID/notifications" | jq
```
Verify
- The team lists the events it subscribes to.

How it works

Approval checkpoints are the most valuable notification target: a paused run costs nothing but blocks delivery until someone decides.

Monitoring alert rules are a separate mechanism from run notifications. Rules evaluate metric conditions and produce alert events.

Implementation evidence

services/nopsai/notification_schema.go
Notification route and mail settings schema.