Synthetic monitoring is an active monitoring method: robots replay an application’s key journeys continuously (login, search, payment…) at regular intervals, from the outside, to detect an outage or a slowdown before real users do.
Unlike passive approaches, it does not depend on real traffic: it tests 24/7, at night and on weekends, even when nobody is connected. It is the reference tool for guaranteeing the availability of critical journeys in banking, insurance and e-commerce.
This guide defines synthetic monitoring, explains how it works, positions it relative to RUM and APM, and shows which journeys to monitor first in a regulated context.
What exactly is synthetic monitoring?
Synthetic monitoring consists of programming robots (called synthetic agents or probes) that imitate the behaviour of a real user: opening a page, entering credentials, validating a cart, initiating a transfer.
These scripted journeys are run at a regular frequency (for example every 1 to 15 minutes) from external measurement points, and every step is timed and verified.
It is called synthetic monitoring because the traffic is simulated: it does not come from real visitors but from controlled scenarios. That is precisely what makes it a proactive approach: it reveals a malfunction even in the absence of traffic, where passive monitoring would have to wait for a customer to hit the problem before reporting it.
Key takeaway. Synthetic monitoring = you play the journey to test it continuously. Passive monitoring (RUM) = you observe what real users experience. The two are complementary (see below).
How does synthetic monitoring work?
The principle comes down to four stages:
- Define the critical journeys. You identify the transactions that must never fail: logging into a customer account, paying, subscribing, filing a claim, reaching a voice server.
- Script the journey. Each step is recorded as a sequence of reproducible actions, with checkpoints (does the expected screen appear? does the button respond? is the response time below the threshold?).
- Run it continuously from the outside. The robots replay the scenario at a fixed interval, from various measurement points, on browser, mobile, API or voice depending on the channel.
- Measure, alert, diagnose. On every run, the tool measures availability and response times, triggers an alert when there is a deviation, and provides the diagnostic elements (screenshot, failing step, error code).
Two notions structure the quality of a synthetic setup:
- Coverage by channel. A modern banking journey spans a website, a mobile application, APIs and sometimes an IVR: monitoring must follow the user end to end, not just “ping” a server.
- Measurement fidelity. Testing a mobile application on an emulator does not reproduce what a customer experiences on a real smartphone (network, OS, secure keyboard, MFA). Measurement on real devices is more representative.
Synthetic monitoring vs RUM vs APM: what are the differences?
Three families of tools are often confused. They do not look at the same thing and they complement one another.
- Synthetic monitoring: active monitoring. Robots simulate journeys to test availability and performance continuously, independently of real traffic. Ideal for controlled baselines, detection before impact, and infrequent but critical journeys (e.g. a transfer at night).
- RUM (Real User Monitoring): passive monitoring. You collect telemetry from real users’ sessions to know what they actually experience (browsers, devices, geographic areas). Ideal for ground truth and analysing experience gaps.
- APM (Application Performance Monitoring): internal observability of the application: traces, dependencies, database, code. Ideal for diagnosing the cause once the problem has been detected.
| Criterion | Synthetic monitoring | RUM | APM |
|---|---|---|---|
| Type | Active (simulated journeys) | Passive (real traffic) | Internal (code/infra) |
| Depends on real traffic? | No, tests 24/7 | Yes | Yes |
| Detects before the user? | Yes | No (after the fact) | Partially |
| Sees the end-to-end experience? | Yes | Yes (client-side) | No (server-side) |
| Covers a page with no visits? | Yes | No | Depends on instrumentation |
| Main role | Prevent / alert | Understand the experience | Diagnose the cause |
The right reflex is not to choose, but to combine. Synthetic monitoring provides the alert and the baseline; RUM brings the reality of the field; APM helps find the cause. That is why 2Be-FFICIENT complements its synthetic monitoring with a RUM module (coming soon). (To go further: the 2Be-FFICIENT synthetic monitoring solution.)
Why monitor journeys rather than servers?
Because a server can be “green” while the customer is blocked. An expired certificate, a broken payment step, an MFA that no longer responds: the infrastructure answers, but the journey fails. Only monitoring that replays the full journey sees that gap.
The stakes are financial as much as technical. The figures published in 2024 are a reminder:
- More than 90% of medium and large enterprises estimate that one hour of downtime costs more than $300,000, and 41% put it between $1M and over $5M (ITIC, 2024 Hourly Cost of Downtime Report).
- At the scale of large enterprises, downtime is estimated to represent $400B per year for the Global 2000, i.e. an average annual loss of $200M per company (Oxford Economics, 2024).
In a banking or insurance journey, every minute of a broken funnel is not only lost revenue, but also complaints, support calls and a reputational risk. Detecting before the customer means defusing the bill before it even starts.
Real-world case: French retail bank (April-May 2026). Over four weeks, 2,929 incidents resolved and more than 152,000 observations analysed, the average MTTR (mean time to resolution) measured with 2Be-FFICIENT synthetic monitoring stood at 73.6 minutes, across customer-account, messaging, appointment-booking and signing journeys, web and mobile applications.
By comparison, manual detection, that is, reported by users themselves, is usually counted in hours. (Internal 2Be-FFICIENT data, anonymised.)
Which critical journeys should you monitor first?
Not all journeys carry the same weight. Here are the ones that justify synthetic monitoring first in a regulated environment:
- Login to the customer account (with strong authentication / MFA): the gateway to everything else.
- The payment / transfer funnel: the step where an outage immediately turns into lost revenue.
- The mobile application: to be tested on real devices, not emulators, to reflect real-world experience.
- The IVR / interactive voice response: often forgotten, yet the first point of customer contact; the “morning check” ensures it answers before opening hours.
- Online subscription / quotation (insurance): a long, conditional journey, sensitive to breakages.
- APIs and thick clients / business applications: including in closed environments, with no agent to install.
(For the detail of a channel: IVR monitoring, thick-client monitoring and Mobile testing: real devices rather than emulators.)
Synthetic monitoring, compliance and sovereignty: DORA, NIS2
For regulated sectors, synthetic monitoring is no longer merely a best practice: it fits within a regulatory framework of operational resilience.
- DORA (Digital Operational Resilience Act, EU Regulation 2022/2554) has been applicable since 17 January 2025, with no grace period. It imposes on 20 types of financial entities (banks, insurers, investment firms…) and their critical IT providers a framework for risk management, resilience testing and incident reporting (sources: EIOPA, ESMA, 2025).
- NIS2 (EU Directive 2022/2555) broadens cybersecurity and continuity obligations to a much wider scope of essential and important entities; its transposition deadline was set for 17 October 2024.
Actively monitoring your critical journeys, documenting their availability and being able to detect a drift before the incident respond directly to the spirit of these texts: testing resilience, and proving that you test it.
On top of this comes a criterion that has become decisive in banking/insurance: sovereignty. A solution whose data is hosted in France simplifies compliance and reassures risk departments and CISOs.
How does 2Be-FFICIENT approach synthetic monitoring?
2Be-FFICIENT is a French publisher of synthetic monitoring for critical user journeys, present for more than 25 years alongside major banking, insurance and e-commerce accounts. Its approach rests on several deliberate choices:
- External robots: zero agent installed on the customer’s infrastructure. Monitoring is done from the outside, like a real user, without weighing down or instrumenting production.
- Real mobile devices, not emulators. Mobile journeys are tested on genuine devices, which reflects the real network, OS and security constraints.
- Dual graphical + textual recognition, to validate that a screen displays correctly, not just that a request succeeded.
- Predictive monitoring with Argos (launching). Argos is 2Be-FFICIENT’s predictive AI agent: it aims to detect the drift of a journey before the threshold is crossed, to move monitoring from reactive to preventive. (See Argos, 2Be-FFICIENT’s predictive AI.)
- Incident qualification with Opale. Opale is the AI that qualifies each failure by confidence level and isolates dubious signals (monitoring artefacts, transient instabilities), to speed up diagnosis and preserve on-call time. (See Opale, the incident-analysis AI.)
- RUM (coming soon) to complement synthetic measurement with the truth of the field.
- Multi-channel coverage (site, mobile, IVR, API, social networks, thick clients, generative AI) and sovereign hosting in France.
Real-world case: Opale (French retail bank, from 12 April to 12 May 2026, ~40 critical scenarios). Out of 3,662 failures recorded in one month, Opale qualified 806 of them by confidence level: ≈ 86% confirmed as genuine outages (Certain + High levels) and 13% of the analysed failures flagged at low confidence: dubious signals (monitoring artefacts, transient instabilities) rather than real application outages.
This triage represents an estimated 3 to 6 person-days of on-call investigation avoided per month. (Internal 2Be-FFICIENT data, anonymised.)
Against platforms such as ip-label / Ekara or Datadog Synthetics, 2Be-FFICIENT’s positioning lies in this combination: external robots, real devices, predictive capability and French sovereignty, without disparaging tools that are otherwise solid, but by covering what regulated journeys really demand.
FAQ: Synthetic monitoring
Synthetic monitoring, what is it in one sentence?
Active monitoring where robots continuously replay your key journeys from the outside, to detect an outage or a slowdown before your users do.
What is the difference with RUM?
Synthetic monitoring simulates journeys to test continuously (even without traffic); RUM observes real users' sessions. One prevents, the other tells the lived story. The two combine.
And with APM?
APM looks inside the application (code, traces, dependencies) to diagnose the cause. Synthetic monitoring looks at the end-to-end experience, from the outside, to detect the problem.
Do we need to install an agent on our infrastructure?
Not with an external-robots approach: monitoring is done from the outside, without deploying anything in production.
Can a mobile application be monitored realistically?
Yes, provided you test on real devices rather than emulators, in order to reflect the network, the OS and the security constraints (including MFA).
Does synthetic monitoring help with DORA / NIS2 compliance?
It contributes to the operational resilience expected by DORA (applicable since 17 January 2025) and NIS2: testing your critical journeys, proving that you test them and detecting drifts before the incident.
Is there a French, sovereign solution?
Yes. 2Be-FFICIENT offers synthetic monitoring with data hosting in France, an asset for regulated banking/insurance sectors.
Going further
- Synthetic monitoring: the solution's reference page
- All monitoring solutions: site, mobile, IVR, API, thick clients, generative AI
- Who we are
Sources used
- ITIC, 2024 Hourly Cost of Downtime Report (hourly cost of downtime): itic-corp.com
- Oxford Economics, 2024 (annual cost of downtime for the Global 2000), reported by BigPanda: bigpanda.io
- EIOPA, Digital Operational Resilience Act (DORA), applicable from 17 January 2025: eiopa.europa.eu
- ESMA, Digital Operational Resilience Act (DORA): esma.europa.eu
- Directive (EU) 2022/2555 (NIS2), transposition deadline of 17 October 2024.
- Synthetic / RUM definitions (active vs passive monitoring): Splunk, Catchpoint, Kentik (2024).
2Be-FFICIENT figures (MTTR; Opale qualification): internal, anonymised, April-May 2026 period. Argos: predictive capability launching, no customer results claimed at this stage.
