Observability Metrics - TEM

Observability Metrics for Transactional Email provide real-time insight into email processing, delivery behavior, and system performance. You can access Observability Metrics in two ways:

myEAS Dashboard
The myEAS Dashboard displays Observability Metrics through pre-defined visualizations. No additional setup is required. Use this option for operational monitoring and quick visibility into email traffic.
Integration into your own platform
You can also integrate metrics into your Prometheus-compatible observability platform through the Retarus federation endpoint. This option gives you full control over dashboards, alerting, filtering, and data retention.

The following sections describe how to configure this integration.

📌 Observability Metrics overview
For a general explanation of Observability Metrics, including data format and access model, refer to Observability Metrics Overview.

Setup overview

Setting up Observability Metrics for Transactional Email consists of three steps.

Step 1: Book the Observability Metrics add-on

Contact your Retarus sales representative to order the Observability Metrics add-on and update your contract.

Step 2: Retarus prepares the setup

The Retarus Operations team sets up your dedicated Observability instance and endpoint.

Step 3: Receive credentials and endpoint

Retarus provides you with the credentials and the specific API endpoint for the Observability instance.

Endpoint and authentication

Endpoint

https://api.retarus.com/stable/retarus/metrics/v1/federate/[your_customer_number]

Authentication

Access requires Basic authentication.

Requirements

Host
You must run a Prometheus server in your environment.
Connectivity
Your system must be able to reach the Retarus Observability Metrics federation endpoint over a public HTTPS connection.
Configuration
Your prometheus.yml configuration file must include a scrape_configs section to retrieve metrics from the Retarus federation endpoint.
Scrape interval
Observability Metrics use a pull-based model. You define the scrape interval in your Prometheus configuration. The minimum supported scrape interval is 1 minute. Shorter intervals do not provide fresher data.

Prometheus scrape configuration

To retrieve metrics, configure your Prometheus server to scrape the Retarus federation endpoint.

CODE

scrape_configs:
  - job_name: federate_retarus
    scrape_interval: 5m
    honor_labels: true
    metrics_path: /stable/retarus/metrics/v1/federate/[your_customer_number]
    scheme: https

    params:
      'match[]':
        - '{__name__=~".+"}'
    
    basic_auth:
      username: [your_username]
      password: [your_password]

    static_configs:
    - targets:
      - 'api.retarus.com:443'

Available metrics

Transactional Email exposes the following core metrics for email processing and delivery:

temudr_count_total
Running counter of all emails (per recipient).
temudr_duration_seconds_sum
Total processing time in the system for a single email.
temudr_duration_seconds_count
Number of data points capturing processing time. This metric is used to calculate the average processing time by dividing temudr_duration_seconds_sum by temudr_duration_seconds_count with the same label filters.

CODE

rate(temudr_duration_seconds_sum{interface="$interface",
status="$status",event_phase="$eventphase"}[$__rate_interval]) /
rate(temudr_duration_seconds_count{interface="$interface", status="$status",
event_phase="$eventphase"}[$__rate_interval])

Metrics labels

Transactional Email metrics include the following labels.

Name	Description	Possible values
`datacenter`	Indicates which Retarus datacenter processed and sent the message.	DE1, DE2, US1, US2, SG1, CH1
`event_phase`	Shows the phase in which the message reached its final processing status.	PRE_PROCESS, PROCESS, DELIVER, SMART_DELIVERY
`event_subtype`	Provides more detailed information about the final status of a message after processing.	VALIDATION_ERROR, INVALID_ADDRESS, FORBIDDEN_RECIPIENT, PROCESSING_FAILED, SUPPRESSED, PREVIOUSLY_BOUNCED, OK, HARD_BOUNCE, SOFT_BOUNCE
`interface`	Indicates the entry interface used to submit the message to the Transactional Email service.	rest, smtp
`status`	Gives general information about the final status of the processed message.	OK, ERROR
`status_code`	The SMTP status response code received by Transactional Email MTAs (Mail Transfer Agents).	See full list: SMTP response codes documentation
`substatus`	Used to group messages according to the three main expected outputs after submitting a job request.	DELIVERED, BOUNCED, DROPPED
`tenant`	Indicates which tenant the Transactional Email Technical Account is assigned to.	multiple
`user_id`	The Technical Account ID under which the message was processed.	multiple

Usage

Use the provided federation endpoint (compatible with Prometheus federation) to retrieve metrics data.
Filter data using federation queries or process it locally within your own system.
Control how long metrics data is retained within your own observability platform.

Observability Metrics vs. Events Webhook

Observability Metrics and the Events Webhook serve different purposes.

Aspect	Observability Metrics	Events Webhook
Purpose	Monitor system health and performance trends	Trigger immediate downstream actions
Use case example	“How many emails have been hardbounced per second over the last hour?”	“What is the recipient domain for email #11235 that has been hardbounced?”
Mechanism	Pull: data is retrieved at defined intervals	Push: Retarus sends data when generated
Period	Defined intervals (via scrape configuration)	Continuous, instant flow
Data type	Aggregated data tracking event rates	Full context of an individual event
Data format	OpenMetrics format	JSON or XML payload
Data destination	Observability platform via a specific API endpoint	Web service via a webhook
Suitable for	Dashboards, capacity planning, threshold-based alerting	Real-time workflows, automation, inter-service communication