1. Product Overview & Introduction

What is Alerting

Alerting is a real-time monitoring system for payment performance metrics.
It helps you detect anomalies or performance issues as soon as they occur, giving you visibility and control over your most critical payment KPIs.

It provides:

Slack and email notifications when a performance issue is detected
A dedicated Dashboard page to explore your alert rules and the incidents they triggered
Full self-serve capabilities to create and manage your own alert rules, organised in folders
A simulation mode to validate an alert rule against historical data before going live

Two concepts to keep in mind:

An alert rule is the configuration you create: what is monitored, under which condition, and who gets notified. It was previously called a monitor, renamed to avoid confusion with the Monitoring tab, which is about analytics.
An incident is an alert triggered by one of your alert rules.

Key Use Cases

Alerting helps you monitor key indicators of payment health:

Latency: Track Payment Provider HTTP latency (95th percentile) to detect downtimes
Error Rate: Track Payment Provider related internal errors to detect technical issues (gateway.internal-error, gateway.unknown-error, gateway.timeout, gateway.upstream-error)
Conversion Rate: Detect performance drops to protect your revenue
Transaction Count: Track payment volumes to detect unusual spikes or drops in traffic
Authorization & capture health: Track 3DS success rate, pending transaction rate and pending capture rate to detect issues that conversion rate alone does not surface

Alert rules can be tailored to two distinct classes of issues: fast, high-impact incidents, such as a payment gateway suddenly going down, where short evaluation windows on high-volume data allow instant detection; and silent, long-running anomalies, where longer evaluation periods on lower-volume signals help surface subtle issues that might otherwise remain unnoticed.

2. Alert Rule Types & Capabilities

Alerting supports two complementary alert rule types:

Rule based alert rules, which trigger when a metric exceeds or falls below a defined threshold.
Smart based alert rules, powered by a seasonal algorithm that automatically defines an adaptative threshold and evaluation period.

Rule Based Alert Rules

Each alert rule is defined by a set of configuration parameters:

Parameter	Description
Rule name	The name of the alert rule, used in the table and in every notification
Folder	Where the alert rule is stored. Defaults to `General` if you don't select or create one
Metric	The metric being tracked: `Conversion rate`, `Transaction count`, `Payment provider error rate`, `Payment provider latency`, `Pending capture rate`, `3DS success rate`, `Pending transaction rate`
Calculation	How the metric is computed against payment attempts: 'Net', 'Raw', or 'Attempt #' (same semantics as in Analytics). Not applicable to Payment provider latency, Payment provider error rate, Pending capture rate and Pending transaction rate
Comparator	The comparison operator used to trigger the alert (`Greater than`, `Less than`)
Threshold	Numeric value that triggers an alert
Evaluation period	Time interval between two evaluations (default: every 5 minutes)
Additional filters	Optional filters to focus on specific data (gateway, currency, transaction metadata, etc.)
Break down by	Optional. Creates one alert rule per value of a dimension (for example one rule per payment provider), all sharing the same configuration
Minimum volume	Minimum volume required to trigger an alert (default: 100). Not applicable to Transaction count
Clear alert after	The number of healthy periods in a row required for an incident to be recovered (default: 1)

Smart Based Alert Rules

Smart based alert rules are powered by a seasonal algorithm that learns from the last 30 days of data and automatically adapts the alert threshold to the metric's expected behaviour at any given time of day. It also defines an optimal evaluation period to have enough volume per period.

This means you no longer need to define a threshold or an evaluation period. The result: easier configuration and more accurate detection, especially for metrics with strong daily patterns.

Smart based alert rules are available on Conversion rate, Transaction count, Payment provider error rate and 3DS success rate. They are particularly well-suited to Conversion rate and Transaction count, where the value naturally fluctuates over time and a static threshold is hard to set.

Payment provider latency, Pending capture rate and Pending transaction rate are only available on Rule based alert rules.

Parameter	Description
Rule name	The name of the alert rule, used in the table and in every notification
Folder	Where the alert rule is stored. Defaults to `General` if you don't select or create one
Metric	The metric being tracked: `Conversion rate`, `Transaction count`, `Payment provider error rate`, `3DS success rate`
Calculation	How the metric is computed against payment attempts: 'Net', 'Raw', or 'Attempt #' (same semantics as in Analytics). Not applicable to Payment provider error rate
Comparator	The comparison operator used to trigger the alert (`Greater than`, `Less than`)
Sensitivity	A percentage that loosens the auto-tuned threshold to reduce noise. 0 keeps the algorithm at its default sensitivity; higher values widen the tolerated range and produce fewer alerts
Additional filters	Optional filters to focus on specific data (gateway, currency, transaction metadata, etc.)
Break down by	Optional. Creates one alert rule per value of a dimension (for example one rule per payment provider), all sharing the same configuration
Minimum volume	Minimum volume required to trigger an alert (default: 100). Not applicable to Transaction count
Clear alert after	The number of healthy periods in a row required for an incident to be recovered (default: 1)

How to choose ?

Use a Rule based alert rule when you have an explicit SLO or business-defined limit (e.g. "latency must stay below 10s").

Use a Smart based alert rule when the metric naturally varies over time and you want to be alerted on deviations from its normal pattern (e.g., conversion rate or transaction count drops that wouldn't be obvious against a fixed threshold).

Simulation

Before creating an alert rule, you can simulate it against historical data to see how it would have behaved in the past. The simulation opens on the last 24 hours, and you can switch to another preset or a custom date range.

Adjust the threshold, filters, calculation or sensitivity, and immediately see which incidents would have triggered, and no notification is sent to your team.

When your alert rule uses a Break down by, the simulation shows one tab per value, so you can check each of them and fine-tune the configuration of a single value before creating the rules.

This is the recommended way to dial in the sensitivity of Smart based alert rules and to validate static thresholds. No more tuning in production !

3. Notifications & Actions

Notification Channels

Each alert rule can fan out alerts and recoveries to multiple destinations: up to 5 Slack channels and 5 email recipients per alert rule. Every notification includes a direct link to the corresponding incident on the Alerting dashboard.

Warning: Slack channels must be on the ProcessOut workspace, contact us if you want to create one !

Deep Dive & Contextual Exploration

From any incident on the dashboard, you can access detailed data views:

Jump to Analytics to analyse trends and segment impact
Jump to Transactions to investigate affected payments in detail

4. Getting Started

Access the Alerting Tab
Go to the Alerting tab in your ProcessOut Dashboard. It has two views:
- Alert rules: your alert rules, grouped by folder and expandable to see each configuration
- Incidents: every alert triggered over the last 7 days
Both views have a search field and filters to quickly find the alert rule or incident you need.
Create Your First Alert Rule
- Click Create rule
- Give it a name and choose the folder it is saved in (General by default)
- Choose between Rule based and Smart based
- Build the condition: metric, calculation, comparator, and threshold (or sensitivity)
- Optionally add filters, and a Break down by to create one alert rule per value
- Add up to 5 Slack channels and 5 email recipients to be notified
- Optionally run a simulation against historical data and tweak the configuration until you're happy with the results, then create the rule
Manage Your Alert Rules
From the Alert rules view you can edit, snooze, move to another folder, or delete one or several alert rules at once. Snoozing stops notifications without deleting the rule.
Investigate Incidents
- Open the Incidents view to see firing and past incidents
- Click an incident to access Analytics or Transactions for detailed investigation

Disclaimer

Alerting is evolving, and this page describes its current version. We are actively improving it to make monitoring more accurate, flexible, and actionable.

Your feedback is essential. Please reach out through your ProcessOut contact or via the support portal to share your experience or suggestions.