CDN cache is warm. The API returned 200. Browser RUM says the document loaded. Front-desk staff are still waiting for the schedule to paint and the encounter note to save. That is the Remedly response-time problem: SaaS health is not the wait the practice feels.
Direct answer: Measure Remedly – cloud EHR, practice management, and RCM for medical practices – response time from what staff see on screen – on the glass – not only from browser RUM, CDN or API latency, synthetic HTTP checks, or “the page returned 200.” Time the interval from a click or key until the expected Remedly UI is visible: schedule ready, chart or encounter open, note saved, claims or payment step complete. That interval is click-to-ready – the number a practice manager, help desk, and IT vendor can share.
Remedly is a cloud-based, customizable EHR plus RCM and practice-management suite (product context: Remedly) – notably for plastic surgery, med spa, and mental health – with practice management, patient portal, analytics, marketing, AI assistant, e-prescribing, eLabs, eFax, and payments, on PC, phone, or laptop. It still paints a GUI. Sister glass methods: Epic and Oracle Health / Cerner (same timer pattern), plus Citrix, RDS, and cloud VDI. EHR framing: Epic / EHR on the glass. This article times Remedly itself.
Why a green SaaS tile is not “Remedly is ready”
Cloud EHRs sit behind HTTPS, CDNs, identity providers, and browsers. Uptime pages, URL checks, API latency, and Real User Monitoring (RUM) tell you the service is reachable and the document finished. They are not a stopwatch for “the schedule painted,” “the encounter opened,” or “the note saved.”
A tab can show a spinner, a skeleton layout, a half-hydrated calendar, or a toast that never confirms – and still count as a successful page load. Client-side rendering and heavy encounter forms sit after the network already said OK. An HTTP generator that hammers login times the front door, not the workflow.
A 200 from the CDN is useful. It is not the same as “the schedule appeared.”
If Remedly is opened inside Citrix, Microsoft RDS, AVD, or other cloud VDI, the split doubles: protocol green still is not Remedly UI ready. ICA/HDX or RDP can stream a spinning browser while the EHR is still hydrating. Host CPU and broker tiles do not close a “Remedly is slow” ticket. Use the Citrix, RDS, and cloud VDI posts above for remoting.
Left column is what network, CDN, API, and SaaS health see. Right column is what front desk, clinical, and billing staff wait on. Only the right column is Remedly response time as a person experiences it.
Which Remedly steps to time
Write the steps before you pick a tool. Four intervals cover most practice UX arguments on browser and remoted-browser sessions:
- Sign-in to usable home – from credentials submitted (or SSO return) until usable Remedly navigation is ready – menus, no full-screen spinner. Not “the IdP redirected” or “the document loaded.”
- Schedule / practice-management ready – from opening the calendar or front-desk view until appointments and controls are usable. Not “the route changed.”
- Chart / encounter / note – from open patient, open encounter, or save note until ready: chart visible, form interactive, save confirmed. Customizable notes and consents make the ready image practice-specific – pin it.
- RCM / claims / payments / portal staff steps – from the click that starts billing, claims, payment, eFax, eLabs, e-prescribe, or a staff-side portal task until that step’s ready state.
Pin the browser build (or published-browser / Workspace image if remoted), display scale, tenant branding, and ready baselines. A timer on a moving theme is a story, not a measurement. When Remedly runs inside Citrix or other VDI, run a logon storm separately from density. Storm stresses login-to-shell; density stresses in-session Remedly work on hosts that already have users.
Time it like a script, not a feeling
On a modern SaaS EHR there is often no reliable DOM event that means “done” – and inside a remoted browser none you can trust from outside the glass. The practical signal is the bitmap:
- StartTimer when the user action happens – submit, click, or key.
- WaitForImage until a baseline of the ready state is visible: home chrome, schedule, encounter, save confirmation.
- StopTimer when that image matches.
The recorded interval is click-to-ready for that step. Image recognition – and OCR when the ready state is text – is how you know the glass painted, without an agent inside Remedly. That is the core of on-the-glass APM.
That pipeline is the same for sign-in, schedule, encounter/note, and RCM steps. Change the start action and the ready image. Keep the timer. The Epic sister post uses the identical glass method for hospital EHR plus ambulatory SaaS.
Stopwatch versus synthetic
A person with a stopwatch can time one Remedly schedule open on a quiet morning. That is a demo, not a measurement program. A one-off cannot give a tail, run at Monday check-in rush, hold concurrent sessions while timing save-note, or attach a screenshot of the failed state. Means hide the damage until the front desk is already saying “Remedly is slow.”
A synthetic does the same StartTimer -> WaitForImage -> StopTimer path as a real browser (or remoted Workspace / Remote Desktop browser), on a schedule or under load, with the same schedule, encounter, and claims-ready baselines – continuous on-the-glass monitoring, or a Remedly load/change test when it ramps virtual users.
If you only have a stopwatch, use it to write the acceptance line – then automate it. Example go-live language (schematic only – not a customer dataset or Remedly SLA): sign-in to usable home at p95 inside budget; schedule ready at p95; open encounter and save note inside budget at p95; fewer than 1 percent of runs hang or miss the ready image.
Continuous watch versus load test
On-the-glass is an idea, not a product SKU. Two jobs share the path:
- CitraTest VU load-tests capacity and change. Freeze the image, walk sign-in -> schedule -> encounter -> RCM, ramp concurrent staff-like users, stop at the written budget. When remoted, run storm and sustain separately. See CitraTest VU load testing.
- CitraTest APM watches production. The same Remedly steps, every N minutes, with alerts and screenshots when glass time slips. See CitraTest APM.
The lab answers how many good concurrent Remedly workflows fit before click-to-ready breaks. The watch answers whether today’s schedule and note-save are still inside the line. Do not use a load-test generator as your only production monitor. No agents inside Remedly’s cloud – each virtual user is another staff browser (or remoted session) driving the UI like a person.
What this is not
- It is not a replacement for CDN, API, uptime, or browser RUM graphs. Keep those for the network and document path.
- It is not an HTTP soak of the login URL or a health endpoint. Keep that for the front door.
- It is not “we have full-stack APM, so Remedly is covered.” Schedule and encounter GUIs are pixels staff wait on, not only traces.
- It is not a claim about Remedly proprietary internals, unpublished SLAs, or customer contracts – only delivered UI readiness on the glass.
- It is not a promise that last month’s number survives a UI redesign, new encounter template, browser update, or a move into Citrix / RDS / AVD. Re-time the glass when the image changes.
Take the interval staff already wait
Remedly response time is click-to-ready on the glass – schedule, chart, note, and RCM ready – not a green CDN or protocol tile. Time sign-in, schedule, encounter/note, and billing steps that generate tickets. When remoted, separate logon storm from density. Use a stopwatch only to write the line; use a synthetic to keep it: CitraTest VU under load or change, CitraTest APM on a continuous watch.
When you need that path without agents in the SaaS tenant – real browser or remoted client, image and OCR, StartTimer to StopTimer for Remedly – schedule a demo. Product pages: on-the-glass APM, CitraTest VU, and CitraTest APM.