RMON Client Checks: Monitoring from the User’s Side

The uptime check is green. A visitor says the site takes forever. Someone replies, “It is fast from the data center.” Congratulations: “works on my machine” has acquired a rack and redundant power supplies.

Both observations can be correct. A scheduled request from an agent and a page opened on a visitor’s phone take different paths and measure different work. RMON’s new Client checks bring measurements from browsers, mobile apps and desktop software into the monitoring picture.

A Client check receives observations sent by your application: whether an operation succeeded, how long it took, custom numeric measurements and the context needed to compare results. You define what to collect and add the measurement and sending code to the application.

Start where the operation happens

With an agent check, RMON asks a service a question on a schedule. With a Client check, an application reports what happened when it performed an operation. One might test an API every minute; the other might report the experience of loading a page, fetching a catalog or synchronizing a document.

This makes Client checks useful for real user monitoring, or RUM, when observations come from actual visitors. The same event format also works for an operation you instrument in mobile or desktop software. Creating the check defines the expected data; it does not automatically instrument your application.

Keep your synthetic checks too. They continue asking questions when nobody visits. Client checks add evidence from the devices, releases and networks your users actually encounter.

Two useful shapes: outcomes and measurements

Some operations have an obvious result. A document synchronized, or it did not. Enable Record success or failure and have your application send ok or error. You can add duration in milliseconds and an error code that helps explain a failure.

Other observations are measurements without a pass or fail: page-load duration, transferred bytes or the number of items processed. Leave outcome recording off and define duration or custom metrics. A slow sample remains valuable evidence without asking the browser to invent a verdict.

Custom metrics have names, units and numeric types. Context carries labels such as environment, platform and application version; you can also define fields for your own comparisons. Keep the meanings stable: “duration” should not quietly change from milliseconds to seconds because a new developer prefers smaller numbers.

Meet two browser-side checks

Page load: what happened after the visitor opened the page?

A page.load check can collect document-load duration together with DNS, connection, TLS, time to first byte, HTML download and DOM-ready timings. Where the browser exposes it, first contentful paint adds a measurement of when content first appeared. These are measurements your integration reads and sends, not values inferred from the RMON server.

The browser’s Navigation Timing API describes document loading, while Paint Timing provides paint milestones. A completed load event does not prove that every later application request or interaction has finished. Measure the operation that matters to your user.

This helps separate “the document arrived quickly” from “the application became useful quickly.” Those sentences are close enough for a slide deck and far enough apart for a support ticket.

Browser HTTP response: can this visitor make another request?

An http.reachability check can make a lightweight HEAD request to your site and record the HTTP status, outcome and time to response headers. Run it against a target you control and handle a timeout as a failed operation.

That measures an HTTP exchange from the visitor’s browser. Its duration includes request and server work; it is not an ICMP Ping or a page-rendering measurement. It also does not verify a response body. If your homepage answers HEAD correctly while checkout is broken, the check will answer the question you actually asked.

The names above describe useful check definitions, not a fixed list of protocols. Client checks also accept your own operation names and measurements.

Example: importing a CSV file in a desktop application

A warehouse application imports a CSV file into a local database. There is no website to request: the useful question is whether the import completed and how much work it did. A perfectly healthy network will not persuade a malformed row to become a date.

Create a Client check with the code inventory.import. Enable Record success or failure and Measure duration in milliseconds. Add two required integer metrics, rows_processed and rows_rejected, with the unit rows and a minimum of zero. Include environment, platform and application version in the context.

Measure from the start of parsing until the application finishes applying the import. Define success according to your import rules. For example, a strict import can report error if any row is rejected, even when earlier rows were applied. Count the rows actually applied, not merely the rows read from the file.

An illustrative failed observation looks like this:

{
  "event_id": "9bc69d8a-5200-4c5e-997c-1377aef6b53c",
  "check": "inventory.import",
  "definition_version": 1,
  "observed_at": "2026-10-13T12:00:00Z",
  "status": "error",
  "duration_ms": 12340,
  "metrics": {
    "rows_processed": 24000,
    "rows_rejected": 1
  },
  "context": {
    "environment": "production",
    "platform": "desktop",
    "app_version": "4.2.0"
  },
  "error": {"code": "invalid_row"}
}

This is one observation for the events array in the JSON body generated on Connect. Replace the example ID, timestamp, version and measurements with the real operation’s values. The CSV processing happens locally; HTTP(S) is used to deliver its observation to RMON. A non-browser sender needs a sending key that allows applications without an Origin header.

In Report, compare duration and rejected-row counts between application versions. In Recent events, inspect the outcome and error code. Keep row contents and customer records out of the event: you need to know that parsing failed, not receive the warehouse’s address book.

Another example: a background archive job

A scheduled job can report archive.create after creating and verifying a local archive, with its duration, files_archived and archive_bytes. Your script performs the work and sends the observation; RMON collects and displays it. Define what verification means for that job, and report errors when it fails.

If the job never starts or crashes before it can send an event, no observation arrives. Client checks do not automatically turn that silence into a missed-job alert. Check that the reported timestamp matches the run you expected.

Connect the first check

1. Open Client checks in RMON and choose New project. Use a project name that identifies the application being measured.
2. Choose New check. Set its code, decide whether it records success or failure, then define duration, custom metrics and useful context. Select a primary metric for the overview.
3. Open Connect and confirm the event endpoint configured for your installation. Issue a sending key scoped to the intended checks and environments. For browser use, set the exact allowed website origin, such as https://shop.example.com, without a path.
4. Select the generated JSON, curl or Browser JavaScript example. Replace its sample values with actual measurements and send them from the application being measured. The example is a starting point for integration, not an automatic page-performance collector.
5. Confirm the observation in Recent events, then open Overview and Report. Reports include completed minutes and may show Processing while new data is being prepared.

A new operation needs a new event ID. If delivery fails temporarily, retry the same event with the same ID and bounded delays. The generated browser example handles retryable network failures and HTTP 429 or 5xx responses. This prevents an uncertain delivery result from becoming several copies of one user action.

When you evolve a check, save a new definition version and send the version your application uses. Older clients can continue sending their previous definition. Changing a field’s type or unit requires a new field or check code, keeping old and new measurements interpretable.

Read the experience, not just the average

The overview shows observation counts, error rate where outcomes exist, and the primary metric. Reports add a timeline, metric statistics and approximate p50, p95 and p99 values. Percentiles help you look beyond the middle of the distribution toward slower experiences.

Compare application versions, environments, platforms, countries or network types when that context is available. Declared filterable custom fields provide additional comparisons. Country information may come from the client or configured IP lookup; IP-based location is approximate.

For an illustrative investigation, suppose a new desktop release has a higher p95 for inventory.import while the previous release is stable. Filter by application version and inspect durations, row counts and errors to check whether the workload also changed. That narrows the investigation; it does not, by itself, identify the cause.

Each metric uses only observations that contain that measurement. Statistics describe the received sample, not an estimate of all visitors. A quiet period can mean no traffic, sampling, blocked delivery or missing instrumentation. It is not automatically zero latency or an outage. Client checks also cannot report from a page that failed before its measurement code could run.

Send useful context, not someone’s account

A sending key can be embedded in an application and permits event submission; it cannot read reports. Scope it narrowly and revoke it when retiring an integration. A key visible in browser code is not proof of a user’s identity.

Source-page addresses keep the host and path and discard query parameters and fragments. Paths, custom context and error messages can still contain sensitive data, so send stable page names and concise diagnostic codes. An email address is rarely the missing ingredient in a latency graph.

Make the first observation earn its place

On a disposable test, send one successful operation and one deliberate failure. Verify the code, version, duration and context in Recent events. After processing, confirm that the report shows both outcomes. For a measurement-only check, verify the metric count and values instead of expecting an error rate.

Then combine the two views: a scheduled HTTP check for a service you depend on, and a Client check for the operation people perform against it. One tells you what your probe observed. The other helps explain what reached the user’s screen. The next “it is slow” conversation can begin with evidence instead of a geography contest.