Alerts in the Integrations section allow you to set up automated monitoring rules that watch your integration logs for specific error patterns and notify the right people when something goes wrong. Instead of manually checking logs for failures, you can define conditions that trigger email notifications — helping your team catch and resolve integration issues before they impact employees.

Alerts are available under Settings → Integrations → Alerts on the dashboard.

---

How Alerts Work

An alert rule continuously monitors your integration logs in the background. When log entries match the conditions you've defined — and the occurrence threshold is met within your specified time window — the system automatically sends an email notification to the configured recipients.

After an alert fires, it enters a cool-off period during which it won't trigger again, preventing notification fatigue from repeated occurrences of the same issue.

---

Alert Rule Types

When creating a new alert, you choose one of two rule types based on what you want to monitor:

Custom (Integrations) Monitors logs from your custom or built-in integrations. Use this to track failures in API calls made to or from third-party systems like Workday, ServiceNow, SAP, and others.

Connector (Synapse) Monitors logs from connector-based workflows and actions. Use this to catch issues in automated operations that execute through your configured connectors.

The rule type you choose determines which condition fields are available for building your alert logic.

---

Creating an Alert Rule

Alert rules are created through a guided three-step wizard.

Step 1 — Set Conditions

Define what the alert should look for in your integration logs.

Alert condition name — Give your rule a descriptive name so it's easy to identify later (e.g., "Workday 401 Auth Failures" or "ServiceNow Timeout Errors").

Alert rule type — Choose between Custom or Connector as described above.

Condition builder — Build one or more conditions that log entries must match to trigger the alert. Each condition consists of a Field, an Operator (such as Equals, Contains, etc.), and a Value.

Available fields depend on the rule type:

Step 2 — Configure Actions and Recipients

Define who gets notified and what the notification looks like.

Type of action — Currently, alerts are delivered via email.

Alert notification recipient — Choose who should receive the alert:

• All integration admins — Sends the notification to every user with integration admin permissions.
• Specific integration admins — Select individual admins from a searchable list.

Subject — Set a custom email subject line so recipients can quickly understand the alert.

Body — Compose the email body using the rich text editor. You can include dynamic variables to provide context about the triggered condition.

Step 3 — Set Frequency

Control how often the alert fires to avoid unnecessary noise.

Occurrences — The number of times the condition must be met before the alert triggers. For example, setting this to 5 means the condition must match 5 log entries before a notification is sent.

Time window — The duration within which the occurrences must happen. You can configure this in days, hours, or minutes. For example, "5 occurrences in 1 hour" means the alert fires only if 5 matching log entries appear within a single hour.

Cool-off period — The waiting period after an alert fires before it can trigger again. This prevents repeated notifications for the same ongoing issue. Configurable in days, hours, or minutes.

---

Managing Alert Rules

Once created, your alert rules appear in the Alerts table with their name and current status. From this table you can:

Edit — Modify any part of an existing alert rule, including its conditions, recipients, or frequency settings.

Enable / Disable — Toggle an alert rule on or off without deleting it. Disabled rules stop monitoring and won't send notifications until re-enabled.

View Logs — Open a side panel showing the history of all times this alert was triggered. Each log entry shows the timestamp, email subject, notification body, and the list of recipients who were notified. You can filter logs by date range to investigate specific incidents.

---

Alert Log Details

When you view logs for a triggered alert, each entry includes:

• Timestamp — The exact date and time the alert was triggered.
• Subject — The email subject line that was sent.
• Body — A preview of the notification content, with an option to view the full details.
• Triggered To — The list of recipients who received the notification, including their names and email addresses.

---

Common Use Cases

Monitor authentication failures — Create a rule that watches for repeated 401 status codes on a specific integration's base URL. Set occurrences to 3 within 15 minutes to catch credential expiry or permission issues early.

Track connector action failures — Use a Connector rule type to monitor a specific app name and action for non-200 status codes. This helps catch workflow breakdowns in automated processes.

Watch for timeout errors — Set up a rule that monitors for 408 or 504 status codes to identify integrations experiencing latency or availability problems.

Alert on specific endpoint failures — Use the Request URL Path Name field to monitor a critical API endpoint (e.g., a payroll submission or employee sync endpoint) and get notified the moment it starts returning errors.

---

Best Practices

• Start with broad rules, then refine. Begin by monitoring high-level indicators like status codes across an integration, then create more targeted rules as you learn which failures are most impactful.
• Use meaningful rule names. Clear names like "SAP Employee Sync 500 Errors" make it easy to identify and manage rules as your list grows.
• Set appropriate cool-off periods. Too short and you'll get repeated alerts for the same incident; too long and you might miss a new occurrence of the same issue.
• Balance occurrences and time windows. A single error might be a transient glitch. Requiring multiple occurrences within a time window helps reduce false positives while still catching real problems.
• Assign alerts to the right people. Use "Specific integration admins" to route alerts to the team members who own that particular integration, rather than notifying everyone.