Overview

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 trigger criteria you've set are met within your specified time window — the system automatically sends an email notification to the configured recipients.

Each rule uses one of two trigger modes: Frequency mode, which fires when a raw count of matching events is reached, or Threshold mode, which fires when the percentage of failing requests crosses a configured threshold (calculated against a minimum request volume). You'll choose between these on Step 3 of the rule creation wizard.

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.

---

Default Alerts

Default alerts are pre-configured alert rules that are automatically set up for all production bots. They act as a fallback monitoring mechanism — ensuring that critical integration failures are detected and flagged even if no custom alert rules have been created.

How Default Alerts Work

• Default alerts are automatically provisioned for every production bot during setup. There is no manual action required to activate them.
• They monitor external/third-party API calls and trigger notifications when failures are detected.
• Notifications are sent to a predefined audience group — a common default email address configured across all bots.
• If a bot already has custom alert rules covering the same conditions, default alerts will not create duplicate rules (the system skips bots that already have an alert with the same name).

Key Characteristics

• Always-on by default: Default alerts are enabled automatically. Administrators can disable them if needed.
• Editable: Like any other alert rule, default alerts can be edited — you can modify their conditions, recipients, frequency, or cool-off period to suit your organization's needs.
• Fallback mechanism: Default alerts ensure baseline monitoring coverage. If no custom threshold is configured for an integration, the default alert rule applies automatically to catch failures.

Managing Default Alerts

Default alerts appear alongside custom alerts in the Alerts table. They can be managed just like any other alert rule:

• Edit — Modify conditions, recipients, or frequency settings.
• Enable / Disable — Toggle a default alert on or off without deleting it.
• View Logs — Review the history of when the default alert was triggered, including timestamps, notification content, and recipient details.

---

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:

Note for Threshold-mode alerts: If you plan to use Threshold mode in Step 3, your conditions must include exactly one Request URL or Request Base URL condition. Threshold mode evaluates failure rate for a single endpoint or base URL, so multiple URL conditions or no URL condition will cause Threshold-mode alerts to fail validation when you click Create alert. Frequency-mode alerts have no such restriction.

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. This field is mandatory. The available options are:

• All integration admins — Sends the notification to every user with integration admin permissions.
• Specific integration admins — Select individual admins from a searchable list.
• No current admins — Use this option when there are no integration admins configured for the bot. When selected, the Custom email addresses field becomes mandatory so that notifications are still delivered.

Custom email addresses — Add one or more external email addresses (comma-separated) to receive alert notifications. This field is optional when "All integration admins" or "Specific integration admins" is selected, but becomes mandatory when "No current admins" is chosen. Custom email addresses receive notifications as CC recipients alongside the primary audience.

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

Decide when the alert should fire by choosing one of two trigger modes and configuring the time-based controls that apply to both. The mode you pick determines whether the alert is driven by a raw count of matching events or by an error-rate percentage.

Choosing a trigger mode

A toggle at the top of Step 3 lets you switch between Frequency and Threshold modes.

Frequency mode triggers when the conditions you defined in Step 1 are met a fixed number of times within a time window. Use this when you want to know about any occurrences of a problem — for example, "alert me as soon as we see 3 timeout errors in 15 minutes."

Threshold mode triggers when the percentage of failing requests crosses a threshold within a time window, calculated against a minimum request volume. Use this when raw counts are noisy and what you really care about is the failure rate — for example, "alert me when more than 5% of Workday calls fail, but only if there have been at least 50 calls in the window."

Threshold mode requires a Request URL or Request Base URL condition. Threshold mode evaluates failure rate for a single endpoint or base URL, so it only works when Step 1 contains exactly one Request URL or Request Base URL condition. This is validated when you click Create alert, and an info banner is shown in earlier steps as a reminder.

Frequency mode fields

Occurrences — The minimum number of matching log entries required to trigger the alert. For example, setting this to 5 means the alert fires only after 5 log entries match the conditions defined in Step 1.

Time window — The look-back period over which occurrences are counted. Configurable in days, hours, and minutes (the total duration must be greater than zero). For example, "5 occurrences in 1 hour" means the alert fires only if 5 matching log entries appear within any rolling 1-hour window.

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

Threshold mode fields

Failure threshold % — The error-rate percentage that must be reached or exceeded for the alert to fire. Accepts a value between 1 and 100. For example, setting this to 10 means the alert fires when 10% or more of requests in the time window are failures.

Minimum volume — The minimum total number of requests required in the time window before the threshold is evaluated. If the total request count is below this number, the alert is skipped — even if the error percentage is high. This prevents misleading alerts during quiet periods (for instance, "1 out of 2 requests failed = 50% error rate" is not statistically meaningful). Set this to a number that reflects the normal request volume of the integration you're monitoring.

Time window — The rolling window over which the failure rate is calculated. Configurable in days, hours, and minutes. The system counts both the total number of matching requests and the subset that failed, then computes the percentage.

Cool-off period — Same behaviour as in Frequency mode: the suppression window after a trigger before the rule can fire again.

How the two modes compare

Choosing between modes

• If you're monitoring a high-traffic integration and care about reliability (e.g., the percentage of Workday or ServiceNow API calls that succeed), Threshold mode gives a more accurate signal and avoids both false positives during traffic spikes and missed alerts during traffic dips.
• If you're monitoring specific error patterns (e.g., 401 auth failures on a particular endpoint, or any occurrence of a 500 error on a critical sync), Frequency mode is simpler and more direct.
• If the integration handles low or irregular volume, prefer Frequency mode — Threshold mode may suppress alerts because the minimum volume isn't met.

---

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.

For Threshold-mode alerts, the log entry also captures the error percentage observed, the total request volume in the window, and the failure count — giving you a complete picture of why the alert fired.

---

Example: Setting up an alert for a failing Workday action inside workflows

This walkthrough shows how a System Admin can configure an alert that fires when a specific Workday connector action — in this scenario, Submit Time Off Request — repeatedly fails inside a live workflow. Use the Connector rule type whenever you want to monitor a particular action exposed by an integration, regardless of which workflow happens to be calling it. Every field on every step is described below — fields you need to fill in for this scenario are shown with example values, and fields you can leave at their defaults are still listed so you know what's on the page.

Step 1: Open the Alerts tab

From the bot dashboard, go to Settings → Integrations and select the Alerts tab. Click + New alert to start configuring.

Step 2: Set conditions

This step defines what counts as a failure worth alerting on. The page has the following fields:

About Alerts rule type: because we want to monitor a connector action, choose Connector. This switches the Field dropdown in the condition builder to expose connector-level operands (App Name, Action, Type of execution, etc.) instead of the raw HTTP-call operands available under Custom.

Field dropdown options under Connector mode

When you click into the Field column of any condition row, these are the operands you'll see:

Build the condition

Use four rows joined by AND:

The Type of execution = RUNTIME row is what keeps the alert quiet during development — without it, every failed test run from the Studio would also trigger the rule.

Click Next.

Step 3: Set actions

This step controls who gets notified and what the email looks like. The page fields are identical to Custom mode:

The recipient options behave the same way as in Custom mode: All integration admins sends to every integration admin on the bot, Specific integration admins lets you pick named recipients, and No current admins lets you type in any email addresses (validated for format).

Click Next.

Step 4: Set frequency

This step controls when the alert fires. The toggle at the top of the page switches between Occurrence and Threshold modes. For this scenario, choose Occurrence, since time-off submissions are not a high-enough-volume action for a percentage-based rule to behave well.

Occurrence mode fields

This reads as: "Fire when 3 Submit Time Off Request failures occur within any 10-minute window, then suppress further triggers for the next hour." The lower occurrence count (3 instead of 5) reflects the lower volume of this specific action — three back-to-back failures of an HR-critical workflow is already worth waking someone up for.

Click Save. The rule becomes active immediately and you'll see it in the alerts list with status Enabled.

Threshold mode fields

If you switch the toggle to Threshold, the page shows these fields instead:

Note: Threshold mode evaluates against a single Request URL or Request Base URL. Since Submit Time Off Request may resolve to more than one underlying URL, prefer Occurrence mode for action-scoped alerts. Use Threshold mode for URL-scoped alerts instead — the example below shows how.

Short example: Threshold mode for Workday tenant auth failures

Use Threshold mode when you want to catch overall integration degradation rather than a specific action failing — a common case is detecting auth or credential issues, where a spike in 401s across the Workday tenant signals expired or rotated credentials. Pick Custom rule type, since Threshold needs a single URL-based condition.

Fires when more than 10% of calls to the Workday tenant return a 401 within any 15-minute window, provided at least 100 calls have happened. Step 3 (recipients, subject, body) is configured the same way as the Occurrence example above.

Threshold mode requires exactly one URL-based condition (Request URL or Request Base URL). You can extend the rule with non-URL conditions like Status code or Request method to scope the alert further, as shown above.

What happens when the alert fires

• Configured recipients receive the email with the subject and body you set up.
• A new entry appears under the Alert logs sidesheet showing the trigger time, the hit count, the error percentage, and who was notified. You can open any entry to see a preview of the email that was sent.
• The cool-off timer starts. The rule resumes evaluating once the cool-off period ends.

Tips for connector-scoped alerts

• Always pin Type of execution = RUNTIME unless you specifically want to be alerted about test-action failures from the Studio.
• If multiple workflows call the same action, scope the alert by Workflow app identifier as well so you can route notifications to the right team. For example, alerts for a Finance reimbursement workflow might go to Finance Ops while alerts for the HR time-off workflow go to IT.
• Pair this alert with a Custom-mode alert on the same Workday base URL — Connector-mode catches action-level regressions, while Custom-mode catches infrastructure-level problems (Workday auth tenant down, certificate expired) that affect every action at once.

Permissions reference

Common Use Cases

Monitor authentication failures (Frequency) — 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 (Frequency) — 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 (Frequency) — 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 (Frequency) — 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.

Monitor degraded API health (Threshold) — For a high-traffic integration like Workday or ServiceNow, configure a Threshold-mode rule on the Request Base URL with a 10% failure threshold and a minimum volume of 100 within a 1-hour window. This surfaces genuine reliability issues without triggering on isolated transient failures.

Detect quiet outages (Threshold) — Set a Threshold-mode rule with a high failure threshold (e.g., 50%) and a moderate minimum volume on a critical endpoint. This catches scenarios where most requests are failing but raw counts haven't yet crossed a Frequency-mode threshold.

---

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.
• Pick the right mode for the integration. Use Frequency mode for low-volume or critical-path integrations where every error matters. Use Threshold mode for high-volume integrations where the failure rate is a more meaningful signal than raw counts.
• Set the minimum volume thoughtfully in Threshold mode. Too low, and the rule may fire during quiet periods on misleadingly high percentages. Too high, and you may miss genuine outages during low-traffic windows. A good starting point is the lower bound of normal hourly traffic for that endpoint.
• 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.
• Leverage default alerts as a safety net. Default alerts provide baseline monitoring out of the box. Customize them as needed, but avoid disabling them unless you have equivalent custom rules in place.
• Use custom email addresses for cross-functional visibility. Add external email addresses to include stakeholders who may not be integration admins — such as IT operations leads or vendor contacts — so they receive timely failure notifications.