Portal Notifications and DLP Alert Thresholds

The Cloud Portal includes a notification system that surfaces operational alerts — DLP threshold breaches, outpost connectivity issues, webhook failures, billing alerts, and security events. Administrators can configure DLP alert thresholds to get proactive alerts when scan activity exceeds expected levels, enabling faster response to anomalies before they become incidents.

---

Notification Types

The portal surfaces five categories of notifications. Each type maps to a specific operational domain and carries a default severity level.

Type	Description	Severity
dlp_threshold	Triggered when blocked or redacted counts exceed a configured threshold within a time window	warning
outpost_offline	Outpost has not sent a heartbeat within the expected interval	error
webhook_failure	Webhook delivery failed after all retry attempts were exhausted	warning
billing_alert	Usage is approaching plan limits or an invoice payment issue was detected	info
security_alert	Suspicious login attempt, session revocation, or API key compromise detected	error

---

Severity Levels

Each notification is assigned one of three severity levels. Severity determines visual treatment in the portal UI and the urgency of the recommended response.

info

Informational notifications require no immediate action. They surface context that may be useful for planning or awareness — for example, a billing alert indicating you are approaching 80% of your monthly plan limit. Review at your convenience.

warning

Warning notifications indicate a condition that may require review or intervention. DLP threshold breaches and webhook failures carry this severity. While not immediately critical, unaddressed warnings can escalate. Review within a reasonable timeframe and determine whether configuration changes are needed.

error

Error notifications require prompt action. Outpost connectivity loss and security alerts carry this severity. An outpost going offline means traffic inspection may be impaired or bypassed depending on your enforcement mode. A security alert may indicate an active credential compromise. Treat error notifications as high priority.

---

Notification Bell

The notification bell is located in the portal header, in the top-right corner next to your user avatar.

Unread badge: When unread notifications are present, a red circle badge displays the unread count over the bell icon. The badge is hidden when the count is zero.

Quick preview dropdown: Clicking the bell opens a dropdown showing the five most recent notifications. Each entry in the dropdown displays:

• An icon representing the notification severity (info, warning, or error)
• The notification title (e.g., “DLP threshold exceeded: blocked_per_hour”)
• A relative timestamp showing how long ago the notification was generated (e.g., “2 hours ago”)

View all link: At the bottom of the quick preview dropdown, a “View all” link navigates to the full notification list at /portal/notifications.

Auto-refresh: The notification system polls every 60 seconds for new notifications. The unread badge updates automatically without requiring a page reload.

Note

The portal notification system is in-app only. It does not send emails, SMS messages, or push notifications. For external alerting, configure a webhook and route dlp_threshold events to your preferred alerting platform.

---

Notification Management

Full Notification List

The full notification list is available at /portal/notifications. It displays all notifications for your organization, with the most recent entries first.

Filters: The list supports the following filters:

• Type — filter by notification type using a dropdown (dlp_threshold, outpost_offline, webhook_failure, billing_alert, security_alert)
• Severity — filter by severity level (info, warning, error)
• Read status — filter by read or unread status to surface only actionable items

Marking as read: Click any individual notification to mark it as read and view its detail. To clear all unread state at once, use the “Mark all as read” button at the top of the list.

Dismissing notifications: Each notification row includes a dismiss action. Dismissing removes the notification from your list view. Dismissal sets a dismissed_at timestamp on the backend record — it does not permanently delete the notification. Dismissed notifications are excluded from the default list view but remain accessible via the API for audit purposes.

Pagination: The notification list displays 20 notifications per page. Use the pagination controls at the bottom of the list to navigate between pages.

---

DLP Alert Thresholds

DLP alert thresholds are monitoring rules that trigger dlp_threshold notifications when DLP scan metrics exceed defined limits within a rolling time window. They give organizations a proactive signal when blocked or redacted activity spikes above normal levels.

Available Metrics

Three metrics are available for threshold configuration:

Metric	Description
blocked_per_hour	Count of blocked requests in the rolling last hour
blocked_per_day	Count of blocked requests in the rolling last 24 hours
redacted_per_hour	Count of redacted responses in the rolling last hour

Threshold Value

The threshold_value is an integer count. When the metric value exceeds this count during an evaluation cycle, the threshold fires and a dlp_threshold notification is created. The notification payload includes the metric name, the current count at trigger time, and the configured threshold value.

Cooldown Period

After a threshold fires, it enters a 1-hour cooldown. The same threshold will not fire again until the cooldown expires, even if the metric remains above the configured value. This prevents notification storms during sustained incidents.

Check Interval

The system evaluates all enabled thresholds every 15 minutes. There is an inherent lag of up to 15 minutes between a metric crossing the threshold and the notification appearing in the portal.

Notification Payload

When a threshold fires, the resulting dlp_threshold notification includes:

• The metric name (e.g., blocked_per_hour)
• The current count at the time of evaluation
• The configured threshold value
• A timestamp of when the threshold fired

---

Configuring Thresholds

Threshold configuration is available at /portal/alert-config.

Threshold List

The alert configuration page displays a table of all configured thresholds for your organization. Each row shows:

• Metric — the metric being monitored
• Threshold value — the count that triggers the alert
• Enabled — whether the threshold is currently active
• Last triggered — the timestamp of the most recent threshold fire, or “Never” if it has not fired

Creating a Threshold

Click “Add threshold” to open the creation form. Fill in:

• Metric — select from the dropdown (blocked_per_hour, blocked_per_day, redacted_per_hour)
• Threshold value — enter an integer count
• Enabled — toggle defaults to on; disable to create the threshold in a paused state

Click “Save” to create the threshold. It will be evaluated on the next check cycle (within 15 minutes).

Editing a Threshold

Click any threshold row to open the edit form. You can update the threshold value or toggle the enabled state. Metric type cannot be changed after creation — delete and recreate if you need a different metric.

Deleting a Threshold

Each threshold row includes a delete button. Clicking it opens a confirmation dialog before the threshold is removed. Deletion is permanent and cannot be undone.

Threshold Limit

Each organization may configure a maximum of 10 thresholds. This limit applies across all metric types combined. If you need to consolidate, consider whether separate blocked_per_hour thresholds at different values can be replaced by a single well-calibrated threshold.

Tip

Start with a blocked_per_hour threshold of 100 for most organizations. Adjust based on your normal traffic volume after a week of observation.

---

API Reference

Full API documentation for alert thresholds and notifications is published in the API Batch 32 reference. The endpoints below are a brief summary for quick reference.

Alert Thresholds API

Method	Endpoint	Description
GET	/v1/orgs/{org_id}/alert-thresholds	List all configured thresholds
POST	/v1/orgs/{org_id}/alert-thresholds	Create a new threshold
PATCH	/v1/orgs/{org_id}/alert-thresholds/{threshold_id}	Update an existing threshold
DELETE	/v1/orgs/{org_id}/alert-thresholds/{threshold_id}	Delete a threshold

Notifications API

Method	Endpoint	Description
GET	/v1/orgs/{org_id}/notifications	List notifications (supports unread_only filter)
PATCH	/v1/orgs/{org_id}/notifications/{notification_id}/read	Mark a single notification as read
PATCH	/v1/orgs/{org_id}/notifications/read-all	Mark all notifications as read
DELETE	/v1/orgs/{org_id}/notifications/{notification_id}	Dismiss a notification

Creating a Threshold via API

All API requests require an organization-scoped JWT in the Authorization header.

curl -X POST https://api.arbitex.ai/v1/orgs/{org_id}/alert-thresholds \
  -H "Authorization: Bearer $ORG_JWT" \
  -H "Content-Type: application/json" \
  -d '{
    "metric": "blocked_per_hour",
    "threshold_value": 100,
    "enabled": true
  }'

Example response:

{
  "id": "thr_01j9xkzp4e2v8bq7m3cndf5r6w",
  "org_id": "org_01j8xkzp4e2v8bq7m3cndf5r6w",
  "metric": "blocked_per_hour",
  "threshold_value": 100,
  "enabled": true,
  "last_triggered_at": null,
  "created_at": "2026-03-15T10:00:00Z",
  "updated_at": "2026-03-15T10:00:00Z"
}

---

Common Configurations

The following configurations address the most common organizational needs. Use them as starting points and calibrate based on observed traffic patterns.

DLP Spike Alert (Most Organizations)

{
  "metric": "blocked_per_hour",
  "threshold_value": 100,
  "enabled": true
}

Purpose: Catch sudden increases in blocked content that may indicate misconfigured DLP rules firing broadly, an unusual data exfiltration pattern, or an application sending unexpected content types. Most organizations will see zero to a handful of blocked requests per hour under normal conditions. A spike to 100 in a single hour warrants investigation.

Daily Volume Threshold

{
  "metric": "blocked_per_day",
  "threshold_value": 500,
  "enabled": true
}

Purpose: Daily awareness of overall DLP activity volume. Use this alongside an hourly threshold if you want both real-time spike detection and a daily ceiling. A blocked_per_day threshold set to 500 will fire if your organization’s cumulative block count for the rolling 24-hour window crosses that mark — useful for identifying steady but elevated DLP activity that might not trigger an hourly alert on its own.

Sensitive Environment (Air-Gapped Outpost Orgs)

[
  {
    "metric": "blocked_per_hour",
    "threshold_value": 10,
    "enabled": true
  },
  {
    "metric": "redacted_per_hour",
    "threshold_value": 5,
    "enabled": true
  }
]

Purpose: Lower thresholds for environments where any DLP activity is noteworthy. Organizations running outposts in air-gapped or classified environments typically have tightly scoped traffic. Even a small number of blocked or redacted events may indicate a policy violation or an unexpected application behavior that requires review. Set thresholds low to ensure no activity goes unnoticed.

Caution

In sensitive environments, low thresholds combined with the 1-hour cooldown can create gaps in alerting during sustained incidents. For high-assurance environments, supplement portal notifications with webhook-based alerting to a SIEM or security operations platform.

---

Troubleshooting

I am not receiving notifications

Verify thresholds are enabled. Navigate to /portal/alert-config and confirm that the relevant thresholds have the enabled toggle set to on. Disabled thresholds are not evaluated.

Check the cooldown. If a threshold fired recently, it will not fire again for 1 hour. The “Last triggered” column on the threshold list shows the most recent fire time. If it shows a recent timestamp, the threshold is in cooldown.

Note that these are in-app notifications only. There are no browser push notifications, emails, or SMS for portal notifications. The notification bell and the /portal/notifications list are the only surfaces. If you need out-of-band alerting, configure a webhook.

Check the evaluation lag. Thresholds are evaluated every 15 minutes. If a metric crossed the threshold less than 15 minutes ago, the notification may not yet have been generated. Wait for the next evaluation cycle.

I am receiving too many notifications

Raise threshold values. If dlp_threshold notifications are firing frequently, your threshold may be set below your organization’s normal traffic baseline. Review your historical blocked count data and set the threshold above the typical daily peak.

Review DLP rule breadth. Frequent threshold firing can also indicate that DLP policies are overly broad and catching content that should not be blocked. Audit recent blocked requests at /portal/audit-log to determine whether the blocks are intentional. If rules are generating false positives, refine the policy before adjusting thresholds.

Use the cooldown to your advantage. The 1-hour cooldown is built in. If you are still receiving high volumes, the underlying DLP activity is likely genuine and the threshold configuration may need a longer-term policy review rather than a threshold change.

A notification shows an unexpected count

Counts in dlp_threshold notifications are point-in-time snapshots captured at the moment the evaluation cycle ran. The actual metric value may have changed by the time you view the notification — traffic continues to flow and the rolling window continues to advance. The count in the notification reflects the value at the 15-minute check boundary, not at the moment you read it. Use the audit log for precise counts over a specific time range.

Note

If a threshold fires and the count appears lower than the configured threshold value, this can occur when the evaluation window rolls forward between the check and the notification delivery. The threshold was genuinely exceeded at check time. This is expected behavior and does not indicate a system error.