Synthetic monitoring · Digital experience monitoring
Monitor what your users actually experience.
Orion DEM robots use your websites, business applications and Citrix desktops the way your users do, every few minutes, from the places they work. When something breaks or slows down, you know which step, the probable reason, and you have the screenshot to prove it.
- Open
portal.example.comDOM: passed - Sign in with
{{secret.PORTAL_PASSWORD}}DOM · vault: passed - Check that “My requests” is visibleCheckpoint: passed
- Click “Search”DOM: failed
- Launch Finance (
.ica) and read the statusSession · OCR: not run
Step 4 failed
The “Search” button is covered by a cookie banner.
- Screenshot at failure
- Video replay
- Probable cause: interface changed
A 200 is not an answer.
Most monitoring stops at the server. It asks whether a URL answers, and the answer is usually yes. Meanwhile someone in accounting has been watching a Citrix login spin for four minutes, and the ticket will land tomorrow with the subject line “slow”.
A robot that signs in, clicks, types and reads the screen the way a person does finds the broken step before the people do. It keeps the screenshot. The next conversation with the application team starts from evidence instead of impressions.
What changes for your team
- Hear it from a robot, not from a user
- Problems show up in Teams, Slack, e-mail or your ticketing tool while people are still working, not the next morning in a complaint.
- Know where it broke, and probably why
- Every incident names the step that failed, the most likely cause and what to check first. Less time spent guessing in a crisis meeting.
- Settle the argument with evidence
- Screenshots, a short video and the time of every step. When a vendor or another team says “it works on our side”, you show what users saw.
- Report in a way management reads
- One experience score per application, SLA tracking, and reports sent automatically every week, month or quarter.
Set up a check without writing code
Whoever knows the application can set up the check: by showing it, by describing it, or by starting from something that already exists.
Remote recorder
Show it once
Use the application through the robot’s screen, as you normally would. The robot remembers each click and replays it.
In a browser it keeps stable selectors (data-testid, #id, visible text). On a remote screen it uses the text under the click (OCR), then a reference image.
AI · grounded on the real page
Describe it in one sentence
“Sign in, look up an order, open the invoice.” Your AI writes the steps.
A Windows robot opens the page first, so the AI works from the buttons and fields that really exist instead of guessing them.
AI · improve
Let AI tidy it up
A raw recording becomes a journey anyone can read, with clear step names and the timings that matter to the business.
Adds checkpoints and sturdier selectors, and moves passwords to the vault, using the page copies from your last test.
cURL · HAR
Reuse what developers already have
A developer pastes a request they already use. It becomes a check in seconds.
cURL commands and HAR files become steps with assertions. Tokens and cookies become {{secret.NAME}} references.
20 templates
Start from a ready-made template
Common cases are already written: a Microsoft 365 sign-in, an ITSM portal, a Citrix application, an API.
20 templates for API, HTTP, web and desktop. Each one lists what is left to fill in.
However it was created, a check is reviewed by a person before it runs. When AI proposes one, Orion DEM checks it first, fixes what is safe to fix and sends the rest back to the AI.
Not technical at all? The “Monitor a journey” assistant asks five simple questions and guides you through the rest.
Bring your own AI
Your AI, your rules. Or no AI at all.
Many companies have already chosen an AI provider, or decided where their data may go. Orion DEM follows that choice: plug in OpenAI, Mistral, Azure OpenAI, NVIDIA, or a model hosted on your own servers.
You use your own account, so there is no AI subscription to buy from us. Each organization in the platform can use its own provider.
- NVIDIA
- OpenAI
- Mistral
- Azure OpenAI
- Ollama
- vLLM
What the AI is shown
- Your description of the journey
- The buttons and fields on the page
- The incident sheet and the step that failed
- Screenshots, only if you tick the box
What it is never shown
- Your passwords and other secrets
- Anything at all unless someone asked: it never runs on its own
AI is optional. Without it, monitoring, alerts and reports work exactly the same.
Websites, business apps, Citrix: one tool
Orion DEM checks websites and APIs, and also the Windows applications and Citrix or remote desktops your teams use every day. The details below are for your technical team.
| Journey | Runs on | How the robot interacts | What you get when it fails |
|---|---|---|---|
| API / HTTP | Linux robot (Docker or systemd), or Windows robot | HTTP(S) requests, assertions, extracted variables, DNS / TCP / TLS / TTFB timings, certificate expiry | Status, response and a timing breakdown by connection phase |
| Web | Windows robot, Edge or Chrome | DOM selectors (CSS, XPath, visible text), image, OCR, mouse, keyboard. Waits until the page settles before each action | A screenshot per step, a video replay, LCP / FCP / CLS / INP |
| Windows desktop | Windows robot | Application launch, windows, image, OCR, mouse, keyboard. DOM for Electron apps | A screenshot per step and a video replay |
| Citrix / RDS / RemoteApp | Windows robot | .ica, RDP and RemoteApp sessions, image, OCR, mouse, keyboard | A screenshot per step and a video replay |
Browser journeys need a Windows robot: there is no headless Linux browser runner today. Web vitals are lab measurements taken by the robot during the run, not field data from your visitors.
From a check to an alert
What happens every time a robot runs one of your checks.
It runs on schedule
From every 30 seconds to once a day. Only during business hours if you wish, skipping public holidays and maintenance.
A robot runs it where your users are
In an office, a branch or a data centre. The robot calls out to Orion DEM, so there is no firewall rule to open.
Every step is timed
You see how long sign-in, search or opening a document took, not just the total. Passwords stay in an encrypted vault.
One glitch is not an incident
A failed run can be retried once automatically, so a single hiccup does not wake anyone up.
Repeated problems become incidents
After a few failures or slow runs in a row, an incident opens with its probable cause and alerts go out. It closes by itself when things are back to normal.
An alert that explains itself
Most tools tell you something is down. Orion DEM also tells you what probably happened, so the right team starts on the right problem.
Automatic · every incident · no AI
- Names the most likely cause: the application itself, the network, a sign-in problem, a page that changed, a certificate, or a problem at one site only.
- Shows the evidence: what changed since the last success, which sites are affected, which other applications share the same server.
- Says what to check first, and sends the cause along with the alert or the ticket.
On request · your AI
- Rewrites the explanation in plain language for anyone in the team.
- Looks at the error screenshot next to the last good one and describes what is on screen.
- Proposes a fix and drafts the text of the ticket.
Your team keeps the last word: a cause confirmed or corrected by a person replaces the automatic one everywhere.
Availability says it works. Apdex says how it felt.
One score between 0 and 1 that says how your users felt, not just whether the application answered. Each run counts as satisfying, tolerable or frustrating against the response times you choose, and a failure always counts as frustrating.
Apdex = (satisfied + tolerating ÷ 2) ÷ runs
- Critical
- SLA missed, or Apdex below 0.70
- Watch
- SLO missed, Apdex below target, or under 25% of error budget left
- Compliant
- Every objective met
Robot infrastructure errors are excluded from availability and from the score. A robot that lost its browser, or a person who took the keyboard back, says nothing about your application.
For the people who build the checks
Studio
- Journey logic
- If / else, loops over a list, try / on error, explicit failure. Built from the step editor, no script file.
- Point at the element
- On a DOM step, click the element on a copy of the page. The selector is computed and checked with the robot’s own rules: unique, N matches, or not found.
- Quality check
- Before a journey runs, the Studio checks business timings, checkpoints, passwords in the vault, parameterised addresses, fixed pauses and a test on a robot.
- Versioned definitions
- Every change is a new version, and the cause analysis knows when the version changed.
Compare
- Location comparison
- One curve per robot with the min / max band. Steps more than 20% apart between sites are flagged.
- Threshold helper
- Median, P95 and max per step, with P95 + 20% proposed as the threshold.
Report
- SLA, SLO, XLA
- Error budget and 7-day burn rate computed on the SLO. One status rule, computed by the server.
- Dashboards
- Widget dashboards per audience. Read-only share links that can be embedded in another tool’s page.
- Scheduled reports
- Pick the blocks, the applications and the period. Sent every Monday, or on the first day of the month or quarter, at 7:00.
- Compliance export
- SLA, SLO, XLA and cumulative downtime per journey, by period or calendar month, as CSV.
One platform for every team, subsidiary or client
Each organization sees only its own applications, robots and results. Your central team can still see everything.
- Each one in its own space
- Applications, robots, results, alerts and passwords stay inside one organization. Nothing crosses from one to another.
- Each one its own settings
- Time zone, how long data is kept, alert channels and AI provider are set organization by organization.
- A central view
- People in the main organization open any other one from a menu, keeping their own rights. Every switch is recorded.
- Rights that match real jobs
- Viewer, operator, designer, administrator. Sensitive actions, like sharing a dashboard publicly or taking control of a robot, can be removed person by person.
Where the robot lives
A robot is a small program installed on a computer or server where your users are. Several robots on the same check compare sites: head office against a branch, inside the network against outside.
Windows robot
- A pre-configured installer: Next, Next, Install. No key to paste.
- A supervisor restarts it if it stops. Dedicated machines can sign in automatically after a reboot.
- Service mode for RDS hosts: the console chooses which user session runs the measurements.
- Updates are requested robot by robot, checked against SHA-256 and an ECDSA signature, and rolled back automatically if the new version does not hold.
Linux robot
- One command installs a systemd service: ephemeral user, read-only system, memory capped at 256 MB.
- Or a Docker container with the same settings.
- Runs API and HTTP journeys, with up to four runs in parallel by default.
While a robot drives the screen, keyboard and mouse belong to it. Press Esc then Enter to take back control. Scheduled runs wait if someone used the machine in the last two minutes.
Plugs into what you already run
Alerts
E-mail (SMTP) · Microsoft Teams · Slack · Webhook signed with HMAC
Monitoring
Prometheus · Grafana (Infinity) · Zabbix · Nagios · Centreon
ITSM and API
EasyVista Service Manager · EVObserve · REST API with OpenAPI description
Built for journeys that carry passwords
- Encrypted vault
- Credentials used in journeys are encrypted with AES-256-GCM, sent to the robot at run time and masked in errors and results.
- Outbound-only robots
- Robots open HTTPS connections to the platform. Never the other way round.
- Console sessions
- HttpOnly, Secure, SameSite=Strict cookies, an anti-CSRF header on every change, bcrypt passwords, login rate limiting.
- Roles and audit
- Viewer, operator, designer, admin. Sensitive rights can be removed per account. Robot updates and session changes require a written reason, and sensitive actions are logged.
- Tenant isolation
- Every query is filtered by organization. Screenshots and replays are served through signed, time-limited links.
- API keys
- Scoped to one organization, never administrator, valid for 90 days, 1 year, 3 years or without expiry.
What we do not claim: no SOC 2 report, no ISO 27001 certificate. If your procurement process needs them, ask us what exists today.
Not there yet
On the roadmap, not in the product. We will say so here when it ships.
- Self-service sign-up
- Native UI Automation for Win32, WPF and Java clients
- SAP GUI scripting
- OpenTelemetry export
- S3-compatible storage for screenshots
Free plan, early access
Start monitoring for free
Sign-up is not self-service yet. Tell us what you want to monitor and the Orion DEM team sets up your workspace, then sends you the details by e-mail.
- Your own isolated organization in the console
- A Linux robot for API and website journeys, installed with one command
- Your own Windows robot for browser, desktop and Citrix journeys
- Free plan limits: [TO COMPLETE]
See what your users see.
Put one robot where your users work and get your first measurement the same day.
Request free access