Synthetic monitoring & uptime for SaaS
When the login jams or the checkout silently stalls, you lose revenue and trust long before a server ping notices. XICTRAQ replays your critical user flows with real browsers, checks API endpoints against SLO thresholds and proves availability to your customers.
Reachable is not the same as working
For a SaaS product it is not the landing page that pays the bills, but the path from login through onboarding to the first successful action. Those paths are also the most fragile: a single faulty frontend deployment, an expired token or a slow database query can paralyse the payment flow while the web server keeps answering with HTTP 200. A plain reachability check sees none of this.
Synthetic monitoring closes this gap. Instead of merely opening a connection, a real browser walks the defined flow — it clicks, types, waits for reactions and asserts that the expected element appears. Only when the payment dialog actually shows up or the dashboard loads after login does the step count as passed. A configurable retry absorbs short-lived hiccups, so not every single stutter immediately registers as an incident.
Beyond that, every modern web app lives on its API. Login tokens, webhooks, search queries and payment endpoints form the backbone — and they should not merely respond but respond within clear time and content bounds. XICTRAQ treats these bounds as measurable service-level objectives, not as a vague gut feeling. With 21 modules from browser and API monitoring through Web Vitals to status page and reporting, the platform covers the paths your revenue actually hangs on.
The critical flow as a step timeline
Each step carries an assertion. Only when it holds does the step count as passed — otherwise screenshot and alert.
Login
Checkout
Onboarding
If an assertion breaks, the configured retry repeats the step up to three times before an incident is raised — separating genuine outages from short-lived flakiness. Entered credentials are stored encrypted, never in plain text.
What you actually secure
Eight building blocks that together capture the difference between up and working.
Login flow as a script
A real browser runs sign-in, input and redirect — with an assertion on the expected dashboard element and a configurable retry against flakiness.
Checkout & onboarding
Multi-step paths like payment or first-run setup are replayed step by step and reported on failure; a screenshot records the failing step.
API thresholds (SLO)
Status code, latency, JSON fields and schema shape can be checked against freely defined SLO bounds — per endpoint.
Multi-node consensus
Three EU nodes in Nuremberg, Helsinki (Finland) and Falkenstein probe in parallel; an outage counts only once several nodes confirm it.
Status page & SLA report
A public status page informs customers in real time; SLA reports document availability and MTTR as an exportable PDF.
Web Vitals
LCP, CLS and INP are measured alongside, so a slower release surfaces before users bounce or churn.
Escalating alerts
If an alert stays unacknowledged it escalates step by step to the next on-call contact — via email, Slack, Teams, Telegram, Discord or webhook.
SSL & domain on watch
Expiring certificates and domain deadlines warn you in time instead of triggering a weekend outage.
Critical flows as a repeatable script
A browser monitor is essentially a small screenplay: open the page, dismiss the cookie banner, fill the email field, enter the password, submit, wait for the dashboard element. Each step can carry an assertion — a text, a visible element, a URL after redirect. If an assertion breaks, the exact step is logged and a screenshot of the failure is captured. So you see not only that something was broken, but at which point and how it looked at the moment of failure.
A common objection is that browser scripts are flaky and constantly produce false alarms. That is exactly what the per-step retry is for (0 to 3 repeats, off by default). Once set, a step that fails once on a slow frame is repeated before an incident fires; only when the failure stays stable does the system raise an alert. Credentials for test accounts are stored encrypted and are not shown again in the editor after saving. This lets you measure a real login without creating a security risk.
When is the effort worth it? Wherever a silent failure directly costs money: registration, payment, onboarding, creating the first project. For non-critical marketing pages a light reachability or Web Vitals check is often enough. A practical order is to first script the one to three flows whose failure would drag you out of bed on a weekend, then expand the net step by step.
From an SLA promise to a measurable SLO
A contract often states an availability commitment, but without measurement it stays a word. A service-level objective turns it into a checkable bound. Per API endpoint you set which status code is expected, how long the response may take at most and which fields the payload must contain. A search might be allowed at most 400 milliseconds and must return an array of hits; a payment endpoint must respond with a defined JSON schema.
If a response exceeds the latency bound or an expected field is missing, the check counts as violated; if the next check fails too, the alert goes through your channels. For authenticated endpoints you store headers or tokens so protected routes are checked too. Because response times are recorded per endpoint, you spot creeping degradations early — for example when a query gets slower over weeks, long before it breaks the hard threshold.
What should you watch when setting thresholds? Too tight a latency bound creates noise, too loose a one swallows real problems. It has proven useful to start from the actually measured percentiles and set the threshold just above the normal peak. Web Vitals complete the picture on the frontend side: an API call can be fast while a large JavaScript bundle worsens the perceived load time.
Reachability check versus real functional monitoring
Where a simple ping stays silent — and what a scripted approach additionally sees.
Simple ping
- Login function: Not covered — the server answers even if sign-in hangs
- Checkout path: Invisible — a blocked pay button does not change the HTTP status
- API latency: Only "reachable / not reachable"
- API content: Not checked
- False alarms: Frequent on a short network glitch at one location
- Load speed: No statement
- Incident analysis: Manual log gathering
- Customer evidence: No solid numbers
- Data location: Varies per provider
XICTRAQ synthetic & SLO
- Login function: A real browser logs in and asserts the dashboard element
- Checkout path: Multi-step script with retry, screenshot of the failing step and a step log
- API latency: Freely set SLO threshold per endpoint; a breach fires an alert
- API content: JSON field, value and schema assertions on the response
- False alarms: Multi-node consensus from three EU nodes dampens single outliers
- Load speed: Web Vitals (LCP, CLS, INP) run alongside and reveal regressions
- Incident analysis: Auto-diagnosis bundles HTTP response, DNS resolution, traceroute and screenshot
- Customer evidence: Live status page + SLA report with availability and MTTR as PDF
- Data location: Platform hosted in Germany, measurement within the EU, DPA under Art. 28
| Aspect | Simple ping | XICTRAQ synthetic & SLO |
|---|---|---|
| Login function | Not covered — the server answers even if sign-in hangs | A real browser logs in and asserts the dashboard element |
| Checkout path | Invisible — a blocked pay button does not change the HTTP status | Multi-step script with retry, screenshot of the failing step and a step log |
| API latency | Only "reachable / not reachable" | Freely set SLO threshold per endpoint; a breach fires an alert |
| API content | Not checked | JSON field, value and schema assertions on the response |
| False alarms | Frequent on a short network glitch at one location | Multi-node consensus from three EU nodes dampens single outliers |
| Load speed | No statement | Web Vitals (LCP, CLS, INP) run alongside and reveal regressions |
| Incident analysis | Manual log gathering | Auto-diagnosis bundles HTTP response, DNS resolution, traceroute and screenshot |
| Customer evidence | No solid numbers | Live status page + SLA report with availability and MTTR as PDF |
| Data location | Varies per provider | Platform hosted in Germany, measurement within the EU, DPA under Art. 28 |
Availability you can prove
B2B customers ask for numbers sooner or later: what was availability last quarter, how fast was an outage resolved, is there a status page? XICTRAQ measures across three distributed EU nodes in Nuremberg, Helsinki (Finland) and Falkenstein with consensus logic — an event counts as an outage only once several nodes confirm it independently. This lowers the risk that a brief network glitch at a single location lands in your statistics as a real outage.
From these measurements a public status page emerges that you can run on your own domain. It shows the live state of your components, historical availability and planned maintenance windows — communicated proactively instead of support working through a wave of identical tickets. On the Agency plan the page can be branded with your own logo and colours, and customers can subscribe to incident notifications via double opt-in. An embeddable widget brings the status straight into your app or help centre.
For contracts and reviews the platform produces SLA reports with availability percentage, downtime durations and mean time to recovery (MTTR) as an exportable PDF. When an incident occurs, auto-diagnosis gathers the context — HTTP response, DNS resolution, traceroute and a screenshot of the failure — so your team does not have to gather logs first. Shortening the analysis phase acts directly on MTTR because the time to a first solid hypothesis goes down.
An incident, step by step
- 1
Imagine a deployment breaks the payment endpoint. The first node reports a violated SLO threshold, a second confirms it shortly after — consensus kicks in and the incident opens. In parallel the browser monitor captures the checkout in its failure state and attaches a screenshot. Auto-diagnosis adds the HTTP response, DNS resolution and a traceroute, so the incident already states that name resolution and network path are fine and the problem sits at the application layer.
- 2
The alert goes out on the first channel, for example Slack and email. If nobody responds within the set window, it escalates to the next on-call contact — so a nighttime outage does not linger just because one person muted their phone. On the public status page the affected component automatically shows as degraded, and subscribed customers get a notification without anyone having to type an update manually.
- 3
Once the cause is fixed, the incident closes as soon as the nodes report green again. In the next SLA report the event appears with duration and recovery time, without anyone maintaining a spreadsheet. This continuous path — detection, diagnosis, escalation, communication, evidence — is the difference between frantic reacting and a traceable process.
The relevant modules in detail
Frequently asked questions
How do I monitor a login flow step by step?
You define the steps as a browser monitor: open the page, enter credentials, submit, wait for the element expected after sign-in. A real browser runs these steps at fixed intervals. If an assertion fails — for example because the dashboard does not load — an alert fires and a screenshot of the failure state is stored. Entered credentials are stored encrypted, not in plain text, and a configurable retry (up to three repeats per step) separates genuine outages from short-lived flakiness.
How does synthetic monitoring differ from a plain ping?
A simple ping only checks whether the server responds. Synthetic monitoring replays a real user interaction and verifies the outcome with assertions. A checkout can be reachable at the server level while the pay button stays unresponsive due to a JavaScript error. A scripted browser monitor catches exactly that kind of case; a ping does not.
Can I check API endpoints with SLO thresholds?
Yes. Per endpoint you define the expected status code, a maximum response time and optionally checks on individual JSON fields, their values or the schema shape. If any of these thresholds is exceeded, the check counts as violated; if the next check fails too, an alert is sent. This makes a service-level objective measurable instead of leaving it as a promise in a contract. Authenticated endpoints can be checked via stored headers or tokens.
How does XICTRAQ avoid false alarms on short network glitches?
Measurement runs across three distributed EU nodes in Nuremberg, Helsinki and Falkenstein. If only one node reports a problem, the consensus logic first treats it as a single outlier; only once several nodes confirm the failure independently does it count as an outage. As a result, a brief routing issue at a single location lands in your statistics as a real outage far less often.
Are there SLA reports with MTTR for my customers?
XICTRAQ produces automatic reports with availability percentage, downtime durations and mean time to recovery (MTTR) over the chosen period. These reports can be exported as PDF and, on the Agency plan, branded with your own logo and colours — useful when you need to prove availability to your own customers.
Does the platform help with incident analysis?
On an incident the auto-diagnosis collects the context automatically: the HTTP response with timings and server IP, DNS resolution, a traceroute and a screenshot of the failure. Instead of gathering logs first, you see the likely starting point right inside the incident — which shortens the time to a first hypothesis and tends to lower MTTR.
What does monitoring cost and is there a free entry point?
There is a permanently free plan that lets you create your first monitors and get to know the interface. Paid plans start at 12 euros per month, cancel monthly, and unlock more monitors, shorter intervals and advanced features. Browser monitors with complex flows and white-label status pages sit in the higher plans.
How often is the check run and how fast does an alert arrive?
The check interval depends on the plan and the monitor type, ranging from short cadences for critical endpoints to more relaxed intervals for non-critical pages. When a threshold is breached or an assertion breaks, the alert goes out through your configured channels, for API checks after two consecutive failed checks. If it stays unacknowledged, it escalates step by step to the next on-call contact, so a nighttime outage does not go unnoticed.
Can I run a status page under my own domain?
Yes. The public status page shows the live state of your components, historical availability and planned maintenance windows. It can be served under your own domain via a CNAME; on the Agency plan you add logo, colours and company name. Customers can subscribe to incident notifications via double opt-in, and an embeddable widget brings the status straight into your app.
Where do the nodes run and where is my data?
Measurement runs across three distributed EU nodes in Nuremberg, Helsinki and Falkenstein; Helsinki is in Finland, not in Germany. The platform itself is hosted in Germany, your data stays within the EU, and a data processing agreement under Art. 28 GDPR is available. The legal assessment in each case remains with you.
Secure the paths that carry your revenue
Start on the permanently free plan and create your first login or checkout monitor. Paid plans begin at €12 per month, cancel monthly, a DPA under Art. 28 GDPR is available, hosted in Germany.