Skip to main content
Alerts in Trusys help you detect and respond to issues in real-time by monitoring system health, functional performance, and security risks.
When configured, alerts automatically track predefined conditions, generate incidents when thresholds are breached, and notify the right stakeholders through preferred channels.
Alerts are organized into three main areas:
  • Incident Dashboard
  • Alert Conditions
  • Notification Channels

Incident Dashboard

The Incident Dashboard provides a centralized view of all alert incidents triggered across your projects. It is the primary interface for monitoring alert activity, investigating issues, and tracking frequency trends. Key Features:
  • Incident List โ€“ View all incidents triggered by breached alert conditions within a selected date range.
  • Frequency Distribution โ€“ Visual summaries of how often alerts have been triggered, helping identify recurring issues.
  • Total Incidents โ€“ Number of incidents recorded during the selected period.
  • Affected Alert Conditions โ€“ Number of alert conditions that triggered incidents.
  • Top Breached Conditions โ€“ Quick access to the most frequently triggered alert conditions.
  • Detailed Incident View โ€“ Each incident includes the triggering condition, timestamp, and application context.
The incident dashboard helps teams quickly assess system stability and prioritize which issues to address first.

Alert Conditions

Alert Conditions define the rules that determine when an incident should be generated. Each condition monitors a specific aspect of your system and triggers alerts when thresholds are breached.

Creating a New Alert Condition

  1. Click New Alert Condition.
  2. Name the condition โ€“ Provide a descriptive label for the alert.
  3. Select Application โ€“ Choose the project/application where the condition will be applied.
  4. Select Notification Channel โ€“ Choose how the alert will be sent. You can also create a new notification channel here if needed.
  5. Select Alert Category โ€“ Alerts can belong to one of five categories:
    Health alerts detect failures in the ingestion and availability of production data.
    • No Traces Received - Useful for detecting pipeline failures or application downtime. Triggers when no logs or traces are received for a configured duration
      • no_traces > X times within a defined time window
    • API Throttling - Detects excessive rate-limiting or upstream API failures
      • failure_count > X times within a defined time window
    • Ingestion Errors - Captures parsing errors, schema mismatches, or failed log ingestion
      • failure_count > X times within a defined time window
    • Time Lag - Detects delays between event occurrence and ingestion, indicating pipeline backpressure or outages
      • p95(event_time_lag_seconds) > X seconds within a time window
    Functional alerts monitor ** monitoring metrics** configured during monitoring setup. Triggers when the metric fails continuously for more than the configured duration
    • failure_metric > X times within a defined time window
    Security alerts track violations of configured security categories. Trigger when failures persist beyond the defined duration failure_vulnerable_category > X times within a defined time window
    Functional evaluation alerts notify you when test cases fail during functional evaluations of the selected application. These alerts are evaluation-driven (not production monitoring) and help teams quickly identify regressions, accuracy drops, or behavioral issues introduced by model or prompt changes.
    Security evaluation alerts notify you when security or policy violations are detected during evaluation runs. These alerts focus on pre-production and continuous security testing, ensuring your application complies with safety, policy, and risk requirements before issues reach production.
  6. Save the condition โ€“ Once configured, the alert condition will be added to your project.

Managing Alert Conditions

  • List of Alert Conditions โ€“ View all configured alert conditions for a project. Each entry shows:
    • Condition name
    • Associated application
    • Notification channel
    • Incident count
    • Last alert triggered on
    • Created on
  • Alert Details โ€“ Click on any alert condition to view all related incidents in chronological order. This helps track recurring breaches and evaluate system health over time.

Notification Channels

Notification Channels define how alert notifications are delivered. Channels ensure the right people or systems are informed when an incident occurs.

Creating a New Notification Channel

  1. Click New Notification Channel.
  2. Name the channel โ€“ Provide a descriptive label for the channel.
  3. Select destination โ€“ Choose between Email or Webhook:
    Enter a list of recipient emails. Multiple addresses should be comma-separated.
    Webhooks enable deep integrations with ticketing tools, incident management systems, or custom applications.

    Webhook Configuration

    • Endpoint URL โ€“ Destination to receive alerts
    • HTTP Method โ€“ POST
    • Headers โ€“ Optional custom headers
    • Body Template โ€“ Fully configurable request body
    Trusys sends alerts using a JSON payload, where users can define their own body structure and inject Trusys variables.

    Context Variables

    • project_id โ€“ Unique identifier of the project
    • workspace_id โ€“ Workspace identifier
    • application_id โ€“ Application identifier
    • application_name โ€“ Human-readable application name

    Alert Metadata

    • alert_id โ€“ Unique alert condition identifier
    • alert_time โ€“ Timestamp when the alert was triggered

    Functional & Security Evaluation Variables

    These variables are available for functional and security evaluation alerts.
    • item.title - Short summary of the failure
    • item.description
      Formatted assertion results including:
      • Assertion name
      • Measured value
      • Score
      • Pass/fail result
      • Failure reason
      • Severity
    • item.prompt โ€“ Input prompt used during evaluation
    • item.response โ€“ Model response
    • item.severity โ€“ Severity level of the failure
    • item.score โ€“ Evaluation score
    • item.assertion_name โ€“ Name of the failed assertion
    • item.assertion_score โ€“ Score for the assertion
    • item.assertion_result โ€“ pass or fail
    • item.assertion_failure_reason โ€“ Reason for failure
    • item.json โ€“ Full raw evaluation payload

    Monitoring Alert Variables

    For monitoring-based alerts (health, functional, or security):
    • item.title
    • item.description
      Includes:
      • Failed traces summary
      • Metric name (functional, security, or health)
      • Alert condition thresholds
    This enables rich, structured alerts for downstream automation.
  4. Save the channel โ€“ Once created, the channel can be linked to any alert condition.

Managing Notification Channels

  • List of Channels โ€“ View all notification channels in the project, including:
    • Channel name
    • Number of alert conditions using this channel
    • Added on date
    • Status (active/inactive)
  • Notification Details โ€“ Click on any channel to view details and see all alert conditions associated with it. This makes it easy to trace who gets notified for each condition.

Summary
  • The Incident Dashboard provides visibility into all triggered alerts and their frequency.
  • Alert Conditions define the rules that trigger incidents and determine what to monitor.
  • Notification Channels control how incidents are communicated to users or external systems.