Use alerting to notify your team when Foveus detects important issue activity.
Alerting helps you move from passive monitoring to active response. Instead of waiting for someone to open the dashboard, Foveus can notify your team when a new issue appears or when an existing issue crosses a threshold.
What alerting does
Foveus alerting lets a workspace:
- create alert channels
- create issue alert rules
- notify teams when issue activity matches a rule
- store alert history for dashboard and audit views
Alerting is configured in the Foveus dashboard. It is not configured through the application SDK or FoveusOptions.
Alert channels
Alert channels define where Foveus sends notifications.
Supported channel types include:
Backend delivery
| Channel | Description |
|---|
slack | Sends alerts to a Slack channel using an incoming webhook. |
email | Sends alerts to one or more email recipients. |
webhook | Stores and validates webhook configuration. Dispatch is not enabled in v1. |
Slack channels
Use Slack when your team triages production issues in a shared channel.
A Slack channel requires a webhook URL.
The webhook URL must use Slack’s incoming webhook format:
https://hooks.slack.com/...
When an alert fires, Foveus sends the issue notification to the configured Slack destination.
Email channels
Use email when alerts should go to one or more recipients.
An email channel requires a to list.
During private beta:
- email channels support up to 10 recipients
- delivery depends on backend email provider configuration
- Foveus uses Resend for email delivery when configured
Webhook channels
Webhook channels are available in the schema and validate HTTPS URLs.
In v1, webhook dispatch is currently suppressed.
Use Slack or email for active alert delivery.
Alert rules
Alert rules define when Foveus should send an alert.
Foveus currently supports issue-based rules.
| Rule type | Fires when |
|---|
new_issue | A new issue is created. |
threshold_exceeded | An issue occurrence count increases and crosses the configured threshold. |
New issue alerts
Use new_issue when you want to know as soon as Foveus detects a new issue pattern.
Example:
Notify #production-alerts when a new active issue is created.
This is useful for:
- new HTTP 500 patterns
- new provider failures
- new exception groups
- new business-rule failures
- newly detected recurring failures
Threshold alerts
Use threshold_exceeded when you only want alerts after an issue becomes frequent enough to matter.
Example:
Notify the team when an issue has more than 10 occurrences in the last hour.
Threshold rules are useful when you want to avoid alerts for one-off failures but still catch repeated patterns.
During private beta, threshold rules use the issue’s occurrence_count_1h. The windowMinutes value may be stored and displayed, but arbitrary custom time windows are not recomputed by the dispatcher yet.
Rule scope
Alert rules can be scoped so they only fire for specific issue activity.
Common scopes include:
| Scope | Description |
|---|
failureTypes | Limit alerts to specific failure types. |
serviceNames | Limit alerts to specific services. |
For example, you can create a rule that only alerts for HTTP errors in orders-api.
serviceNames: orders-api
failureTypes: http_error
This keeps alert noise lower and helps route alerts to the right team.
Cooldown
Alert rules can use cooldownMinutes.
Cooldown prevents Foveus from repeatedly alerting for the same issue and rule within a short period.
For example:
This means Foveus should avoid sending repeated alerts for the same issue/rule combination within the cooldown window.
Use cooldowns to reduce alert fatigue.
Alert history
Foveus stores alert history so teams can review what was sent.
Alert history can help answer:
- which issue triggered an alert
- which rule matched
- which channel was used
- when the alert was sent
- whether dispatch succeeded or failed
This is useful for dashboard views, troubleshooting, and audit history.
Recommended alerting setup
For most teams, start with two rules:
1. New critical issue alert
Use this to catch new failure patterns.
Rule type: new_issue
Service scope: production services
Failure types: http_error, exception, provider_failure
Channel: Slack
Cooldown: 15–30 minutes
2. Repeated issue threshold alert
Use this to catch issues that are becoming noisy.
Rule type: threshold_exceeded
Threshold: 10 occurrences
Window: 1 hour
Channel: Slack or email
Cooldown: 30–60 minutes
During private beta, threshold checks use occurrence_count_1h.
Alerting and issues
Alerting is issue-driven.
This means alerts fire from issue activity, not from every individual log line or request.
That keeps alerts focused on meaningful patterns instead of raw telemetry noise.
Use alerts to bring attention to issues. Use issue detail and execution detail to investigate the evidence.
Alerting and executions
An alert points you to an issue.
The issue points you to linked executions.
Executions show the request, response, timeline, logs, outcome, and failure evidence.
This flow helps your team move from notification to investigation:
Alert → Issue → Representative execution → Timeline and logs
Troubleshooting
Slack alerts are not delivered
Check that:
- the alert channel is active
- the Slack webhook URL starts with
https://hooks.slack.com/
- backend alerting is enabled
- the rule is active
- the issue matches the rule scope
- the rule is not inside its cooldown window
Email alerts are not delivered
Check that:
- the email channel has recipients
- the recipient list has 10 or fewer addresses
- backend email delivery is configured
- the rule is active
- the issue matches the rule scope
- the rule is not inside its cooldown window
Threshold alerts do not fire
Check that:
- the issue occurrence count increased
occurrence_count_1h crossed the threshold
- the issue matches service and failure-type filters
- the cooldown window has passed
During private beta, threshold alerting uses occurrence_count_1h. Custom windowMinutes behavior may be expanded later.
Webhook alerts do not fire
Webhook dispatch is not enabled in v1.
Use Slack or email for active alert delivery.
Private beta limitations
During private beta:
- Slack and email are the primary alert delivery channels.
- Webhook channel validation exists, but dispatch is suppressed in v1.
- Threshold rules use
occurrence_count_1h.
windowMinutes may be stored and displayed, but arbitrary threshold windows are not recomputed yet.
- Alerting behavior may evolve as the dashboard and backend mature.
What to do next