Skip to main content
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

​
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:
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.

​
New issue alerts

Use new_issue when you want to know as soon as Foveus detects a new issue pattern. Example:
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:
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: For example, you can create a rule that only alerts for HTTP errors in orders-api.
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. For most teams, start with two rules:

​
1. New critical issue alert

Use this to catch new failure patterns.

​
2. Repeated issue threshold alert

Use this to catch issues that are becoming noisy.
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:

​
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