Journey monitoring

Your tests stop at CI. Your critical journeys do not.

A signup journey that breaks in production almost never breaks at deploy time: it degrades on a Thursday evening, at a router, on one domain. The only way to know is to replay it continuously, verification code included.

datadog · step 2Synthetics

// Step 2 of a Datadog Synthetics multistep test.
// The API waits for the message: no sleep in the scenario.
POST https://api.facteur.eu/v1/messages/await
Authorization: Bearer {{ FACTEUR_READONLY_KEY }}

{
  "inbox": "my-prod-flow",
  "sentTo": "signup+{{ RUN_ID }}@my-prod-flow.inbox.facteur.eu",
  "timeout": 45000
}

// Step assertions
// status            is 200
// body.otp          matches ^[0-9]{6}$
// body.deliveryMs   is less than 15000
// → extract body.otp into the OTP variable for step 3

monitor.yamlDatadog

# A Datadog monitor on the metric we expose.
name: "Signup OTP — reception latency"
type: metric alert
query: >
  avg(last_5m):p95:facteur.message.delivery_seconds{
    inbox:my-prod-flow, type:email
  } > 20
message: |
  The signup code is taking more than 20 s to arrive.
  The journey is not broken, it is on its way to being.
  @opsgenie-oncall

The scenario

What a monitored journey really checks

An HTTP check on your signup page tells you it responds. It does not tell you that a user can sign up.

1
The monitor creates an account on your production environment, with a unique address in your monitoring inbox.
2
It waits for the verification code. Our API blocks until it arrives, and measures the delay.
3
It extracts the code — already isolated from the body — and completes the signup.
4
It deletes the test account, and starts again in five minutes.
→
The day your email router starts taking three minutes, you know before your users do. And you have the metric to prove it to your provider.

What it takes

Monitoring is not testing

Stable addresses, not disposable ones

monitoring inbox

A monitoring inbox lives for months: its address is declared in your monitor, in your synthetics tool, sometimes in an allow list on the sender side. It must not be recycled between runs like a CI inbox.

Capacity reserved for monitoring

the important bit

Your monitors must never be starved of quota by a load test running alongside. An inbox marked “monitoring” has its own reserve: even with the account exhausted, it keeps accepting. A monitoring tool that goes blind when CI runs away is worthless.

Reception latency is a metric

facteur.message.delivery_seconds

Every message carries the delay between SMTP acceptance and availability through the API. That is what you monitor: an OTP taking forty seconds has not failed, but your signup journey is already broken for the user.

Read-only keys

A monitor must not be able to create or delete anything. A key restricted to one inbox, read-only, with expiry and IP restriction — which limits the damage if it leaks into a synthetics configuration.

Performance mode

For a monitor, all that matters is that the message arrived and how long it took. In performance mode we confirm reception, measure, and store nothing: no data lying around, and no retention cost.

Real escalation

A signup journey broken at 3 am is an on-call page, not a notification. Alerts go to OpsGenie or PagerDuty with the priority you choose.

Integrations

From the tool you already use

There is nothing to install: a read-only key and an HTTP call that waits.

Datadog Synthetics

Multistep API test: trigger the journey, wait for the message, extract the code, carry on.

Grafana Synthetic Monitoring

Same principle through scripted k6 checks.

Checkly

Playwright scenarios run continuously, with our Node SDK.

StatusCake, Uptrends

For the simple checks: does the message arrive, and how fast.

Your own scheduler

A cron and two HTTP calls are enough. The API waits for the message on your behalf.

Monitor what actually matters

A journey validated by email or SMS, replayed every five minutes, with reception latency as a metric.

Create a free account Migration guide