Epicor Looked Fine. The Line Stayed Blank.

Posted on by
Epicor Looked Fine. The Line Stayed Blank.
Tevron editorial illustration: ERP status is green. The order line still isn't ready.

ERP status is green. HTTPS returned 200. The Epicor portal loaded. The order line (or inventory grid, or shop-floor step) is still spinning. Status pages and URL checks look healthy. Planners, buyers, warehouse, and shop-floor leads are still waiting for Epicor – Kinetic-class cloud or on-prem ERP for manufacturing and distribution – to paint. That is the Epicor response-time problem: “up” is not the wait people feel on screen.

Direct answer: Measure Epicor response time from what users see on screen (on the glass) – not only from ERP/plant status tiles, CDN or API 200s, or “the portal loaded.” Time the interval from a click or key until the expected Epicor UI is visible: sign-in to usable home/chrome, order or inventory step to ready confirmation, shop-floor / MES-class step to ready, and report / posting confirmation to ready. That interval is click-to-ready – the number an ops lead, ERP team, and help desk can share.

Epicor is industry ERP for manufacturing, distribution, and related supply-chain work – orders, inventory, shop floor, and financials – delivered as Kinetic-class cloud or on-prem UIs (product context: Epicor). Tevron is not affiliated with Epicor; Epicor is a trademark of its respective owners. Sister glass methods: Paylocity, Wave, Deloitte, Sage, Remedly, Oracle Health / Cerner, Epic EHR, Citrix, RDS, and cloud VDI. Method framing: on-the-glass APM, CitraTest VU, and CitraTest APM.

Why green ERP status is not “Epicor is ready”

Epicor sits behind HTTPS, CDNs, identity, and browsers – and often a remoted desktop if someone opens Kinetic-class screens inside Citrix, Microsoft RDS, or AVD. Uptime pages, URL checks, API latency, and “the portal finished loading” tell you the service is reachable and the document arrived. They are not a stopwatch for “the home chrome painted,” “the order line confirmed,” “the shop-floor step saved,” or “the posting is ready.”

A tab can show a spinner, a skeleton order grid, a half-hydrated inventory panel, or a toast that never confirms – and still count as a successful page load or HTTP 200. Client-side rendering and heavier report or posting views sit after the network already said OK. An HTTP generator that hammers login times the front door, not the manufacturing or distribution workflow.

A green ERP status card is useful. It is not the same as “the order line is ready.”

If Epicor is opened inside Citrix, Microsoft RDS, AVD, or other cloud VDI, the split doubles: protocol green still is not Epicor UI ready. ICA/HDX or RDP can stream a spinning browser while orders or shop-floor steps are still hydrating. Host CPU and broker tiles do not close a “Epicor is slow” ticket on the floor. Use the Citrix, RDS, and cloud VDI posts above for remoting.

Schematic: Epicor ERP status, HTTPS 200, and portal loaded do not equal on-the-glass ready states for home, order/inventory, shop floor, and report or posting.
Schematic from this article: ERP status and HTTP health versus glass time. Not a customer dashboard and not a measured Epicor tenant.

Left stack is what ERP status, HTTPS, and the browser document path see. Right stack is what planners and the shop floor wait on. Only the glass stack is Epicor response time as a person experiences it.

Which Epicor steps to time

Write the steps before you pick a tool. Four intervals cover most UX arguments on Epicor orders, inventory, shop floor, and financials:

  1. Sign-in to usable Epicor home / chrome – from credentials submitted (or SSO return) until usable Epicor navigation is ready – menus, company or plant context, no full-screen spinner. Not “the IdP redirected” or “the portal loaded.”
  2. Order / inventory step to ready confirmation – from starting an order-line, pick, or inventory action until that step’s ready state on glass – line accepted, or grid confirmation painted. Not “the route changed.”
  3. Shop-floor / MES-class step to ready – from the click that starts a job, clock, or other shop-floor step until that step’s ready confirmation on glass. Pin the ready image for your Kinetic-class (or on-prem) build and branding.
  4. Report / posting confirmation to ready – from the click that starts a report, journal, or posting until results or confirmation paint – the step that often generates “still waiting” tickets around period close and high-volume shipping days.

Pin the browser (or published-app / Workspace image if remoted), display scale, tenant branding, and ready baselines. A timer on a moving theme is a story, not a measurement. When Epicor runs inside Citrix or other VDI, run a logon storm separately from density. Storm stresses login-to-shell; density stresses in-session Epicor work on hosts that already have users.

Time it like a script, not a feeling

On a modern Epicor web UI there is often no reliable DOM event that means “done” – and inside a remoted thick or Kinetic-class client 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, order/inventory confirmation, shop-floor / MES ready, report / posting 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 the Epicor tenant. That is the core of on-the-glass APM.

Four-step Epicor pipeline: StartTimer, WaitForImage, and StopTimer for home, order/inventory, shop-floor/MES, and report or posting click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for home, order/inventory, shop-floor / MES, and report / posting steps. Change the start action and the ready image. Keep the timer. Sister posts use the identical glass method for HCM, finance suites, EHR, consulting apps, and remoted desktops.

Stopwatch versus synthetic

A person with a stopwatch can time one order-line open on a quiet morning. That is a demo, not a measurement program. A one-off cannot give a tail, run at shipping rush, hold concurrent planner-like sessions while timing a shop-floor or posting step, or attach a screenshot of the failed state. Means hide the damage until ops is already saying “Epicor is slow.”

A synthetic does the same StartTimer – WaitForImage – StopTimer path as a real browser (or remoted client), on a schedule or under load, with the same home, order/inventory, shop-floor / MES, and report / posting ready baselines – continuous on-the-glass monitoring, or a 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 language (schematic only – not a customer dataset or Epicor SLA): sign-in to usable home at p95 inside budget; order / inventory ready at p95; shop-floor / MES inside budget at p95; report / posting ready 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 home – order/inventory – shop-floor / MES – report / posting, ramp concurrent planner-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 steps, every N minutes, with alerts and screenshots when glass time slips. See CitraTest APM.

The lab answers how many good concurrent Epicor workflows fit before click-to-ready breaks. The watch answers whether today’s order, inventory, shop-floor, and posting steps are still inside the line. Do not use a load-test generator as your only production monitor. No agents inside the Epicor tenant – each virtual user is another browser (or remoted session) driving the UI like a person.

What this is not

  • It is not an Epicor SLA claim, uptime scorecard, or substitute for Epicor status pages. Keep those for service reachability.
  • 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 Epicor is covered.” Order, inventory, shop-floor, and posting GUIs are pixels users wait on, not only traces.
  • It is not a claim about Epicor proprietary internals, unpublished SLAs, or mobile-app private APIs – only delivered UI readiness on the glass.
  • It is not a promise that last month’s number survives a UI redesign, new branding, browser update, or a move into Citrix / RDS / AVD. Re-time the glass when the image changes.

Take the interval users already wait

Epicor response time is click-to-ready on the glass: home, order / inventory, shop-floor / MES, and report / posting ready – not a green ERP status tile or HTTP 200. Time the steps that generate tickets when Epicor is “up” but the order line is not ready. 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 Epicor tenant – real browser or remoted client, image and OCR, StartTimer to StopTimer for Epicor – schedule a demo. Product pages: on-the-glass APM, CitraTest VU, and CitraTest APM.

Epicor and Kinetic are trademarks of their respective owners. Citrix and related marks are trademarks of their respective owners. Tevron is not affiliated with Epicor or those vendors. Names are used for identification only.

Paylocity Opened. The Stub Still Hadn’t Drawn.

Posted on by
Paylocity Opened. The Stub Still Hadn’t Drawn.
Tevron editorial illustration: Payroll status is green. The pay stub still isn't ready.

Payroll status is green. HTTPS returned 200. The Paylocity portal loaded. The pay stub (or time entry, or benefits step) is still spinning. Status pages and URL checks look healthy. Payroll admins, HR, and employees are still waiting for Paylocity HCM – payroll, time and attendance, benefits, or self-service – to paint. That is the Paylocity response-time problem: “up” is not the wait people feel on screen.

Direct answer: Measure Paylocity response time from what users see on screen (on the glass) – not only from payroll/HR status tiles, CDN or API 200s, or “the portal loaded.” Time the interval from a click or key until the expected Paylocity UI is visible: sign-in to usable home/chrome, payroll or pay-run step to ready confirmation, time entry or employee self-service step to ready, and report / pay stub / benefits confirmation to ready. That interval is click-to-ready – the number a payroll lead, HRIS team, and help desk can share.

Paylocity is cloud HCM / payroll / HR software for mid-market organizations – payroll, time and attendance, benefits, talent, employee self-service, onboarding, and reporting – delivered on web and mobile (product context: Paylocity). Tevron is not affiliated with Paylocity; Paylocity is a trademark of its respective owners. Sister glass methods: Citrix, RDS, cloud VDI, Epic, Oracle Health / Cerner, Remedly, Sage, Deloitte, and Wave. Method framing: on-the-glass APM, CitraTest VU, and CitraTest APM.

Why green payroll / HR status is not “Paylocity is ready”

Paylocity sits behind HTTPS, CDNs, identity, and browsers – and sometimes a remoted desktop if someone opens it inside Citrix, Microsoft RDS, or AVD. Uptime pages, URL checks, API latency, and “the portal finished loading” tell you the service is reachable and the document arrived. They are not a stopwatch for “the home chrome painted,” “the pay run confirmed,” “time entry saved,” or “the pay stub is ready.”

A tab can show a spinner, a skeleton payroll grid, a half-hydrated benefits panel, or a toast that never confirms – and still count as a successful page load or HTTP 200. Client-side rendering and heavier report or pay-stub views sit after the network already said OK. An HTTP generator that hammers login times the front door, not the payroll or HR workflow.

A green payroll status card is useful. It is not the same as “the pay stub is ready.”

If Paylocity is opened inside Citrix, Microsoft RDS, AVD, or other cloud VDI, the split doubles: protocol green still is not Paylocity UI ready. ICA/HDX or RDP can stream a spinning browser while payroll or self-service is still hydrating. Host CPU and broker tiles do not close a “Paylocity is slow” ticket on payday. Use the Citrix, RDS, and cloud VDI posts above for remoting.

Schematic: Paylocity payroll/HR status, HTTPS 200, and portal loaded do not equal on-the-glass ready states for home, payroll step, time entry, and pay stub or benefits.
Schematic from this article: payroll/HR status and HTTP health versus glass time. Not a customer dashboard and not a measured Paylocity tenant.

Left stack is what payroll/HR status, HTTPS, and the browser document path see. Right stack is what admins and employees wait on. Only the glass stack is Paylocity response time as a person experiences it.

Which Paylocity steps to time

Write the steps before you pick a tool. Four intervals cover most UX arguments on Paylocity payroll, time, benefits, and self-service:

  1. Sign-in to usable Paylocity home / chrome – from credentials submitted (or SSO return) until usable Paylocity navigation is ready – menus, company context, no full-screen spinner. Not “the IdP redirected” or “the portal loaded.”
  2. Payroll / pay run step to ready confirmation – from starting a payroll or pay-run action until that step’s ready state on glass – run progress done, or confirmation painted. Not “the route changed.”
  3. Time entry or employee self-service step to ready – from the click that starts time entry, punch correction, or another ESS step until that step’s ready confirmation on glass. Pin the ready image for your Paylocity build and branding.
  4. Report / pay stub / benefits confirmation to ready – from the click that starts a report, pay-stub view, or benefits confirmation until results or confirmation paint – the step that often generates “still waiting” tickets around payday and open enrollment.

Pin the browser (or published-app / Workspace image if remoted), display scale, tenant branding, and ready baselines. A timer on a moving theme is a story, not a measurement. When Paylocity runs inside Citrix or other VDI, run a logon storm separately from density. Storm stresses login-to-shell; density stresses in-session Paylocity work on hosts that already have users.

Time it like a script, not a feeling

On a modern Paylocity web UI 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, payroll confirmation, time entry or ESS ready, report / pay stub / benefits 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 the Paylocity tenant. That is the core of on-the-glass APM.

Four-step Paylocity pipeline: StartTimer, WaitForImage, and StopTimer for home, payroll, time entry or ESS, and report or pay stub click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for home, payroll, time entry / ESS, and report / pay stub / benefits steps. Change the start action and the ready image. Keep the timer. Sister posts use the identical glass method for EHR, finance suites, consulting apps, and remoted desktops.

Stopwatch versus synthetic

A person with a stopwatch can time one pay-stub open on a quiet morning. That is a demo, not a measurement program. A one-off cannot give a tail, run at payday rush, hold concurrent employee-like sessions while timing a payroll or time-entry step, or attach a screenshot of the failed state. Means hide the damage until HR is already saying “Paylocity is slow.”

A synthetic does the same StartTimer – WaitForImage – StopTimer path as a real browser (or remoted client), on a schedule or under load, with the same home, payroll, time entry / ESS, and report / pay stub ready baselines – continuous on-the-glass monitoring, or a 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 language (schematic only – not a customer dataset or Paylocity SLA): sign-in to usable home at p95 inside budget; payroll / pay-run ready at p95; time entry / ESS inside budget at p95; report / pay stub / benefits ready 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 home – payroll – time entry / ESS – report / pay stub, ramp concurrent employee-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 steps, every N minutes, with alerts and screenshots when glass time slips. See CitraTest APM.

The lab answers how many good concurrent Paylocity workflows fit before click-to-ready breaks. The watch answers whether today’s payroll and self-service steps are still inside the line. Do not use a load-test generator as your only production monitor. No agents inside the Paylocity tenant – each virtual user is another browser (or remoted session) driving the UI like a person.

What this is not

  • It is not a Paylocity SLA claim, uptime scorecard, or substitute for Paylocity status pages. Keep those for service reachability.
  • 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 Paylocity is covered.” Payroll, time, benefits, and self-service GUIs are pixels users wait on, not only traces.
  • It is not a claim about Paylocity proprietary internals, unpublished SLAs, or mobile-app private APIs – only delivered UI readiness on the glass.
  • It is not a promise that last month’s number survives a UI redesign, new branding, browser update, or a move into Citrix / RDS / AVD. Re-time the glass when the image changes.

Take the interval users already wait

Paylocity response time is click-to-ready on the glass: home, payroll / pay run, time entry / ESS, and report / pay stub / benefits ready – not a green payroll status tile or HTTP 200. Time the steps that generate tickets when Paylocity is “up” but the pay stub is not ready. 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 Paylocity tenant – real browser or remoted client, image and OCR, StartTimer to StopTimer for Paylocity – schedule a demo. Product pages: on-the-glass APM, CitraTest VU, and CitraTest APM.

Paylocity is a trademark of its respective owners. Citrix and related marks are trademarks of their respective owners. Tevron is not affiliated with Paylocity or those vendors. Names are used for identification only.

When Wave Is Up but the Invoice Isn’t Ready

Posted on by
When Wave Is Up but the Invoice Isn’t Ready
Tevron editorial illustration: Wave status is green. The invoice UI is still spinning.

Wave status is green. HTTPS returned 200. The browser tab loaded. The invoice (or payroll) UI is still spinning. Status pages and URL checks look healthy. Freelancers, solopreneurs, and contractors are still waiting for Wave accounting, invoicing, payments, or payroll to paint. That is the Wave response-time problem: “up” is not the wait the business feels on screen.

Direct answer: Measure Wave response time from what users see on screen (on the glass) – not only from uptime tiles, CDN or API 200s, or “the document loaded.” Time the interval from a click or key until the expected Wave UI is visible: sign-in to usable dashboard/chrome, create or send invoice (or estimate) to ready confirmation, payment/receive or online pay step to ready, and report/books/payroll step to ready. That interval is click-to-ready – the number an owner, bookkeeper, and help desk can share.

Wave is small-business software for web-based accounting, invoicing, payments, payroll, and reports – no install for the online tools, with a mobile app companion – built for freelancers, solopreneurs, and contractors (product context: Wave). Tevron is not affiliated with Wave; Wave is a trademark of its respective owners. Sister glass methods: Citrix, RDS, cloud VDI, Epic, Oracle Health / Cerner, Remedly, Sage, and Deloitte. Method framing: on-the-glass APM, CitraTest VU, and CitraTest APM.

Why green uptime is not “Wave is ready”

Wave sits behind HTTPS, CDNs, identity, and browsers – and sometimes a remoted desktop if someone opens it inside Citrix, Microsoft RDS, or AVD. Uptime pages, URL checks, API latency, and “the tab finished loading” tell you the service is reachable and the document arrived. They are not a stopwatch for “the dashboard chrome painted,” “the invoice sent confirmation showed,” or “payroll confirmed.”

A tab can show a spinner, a skeleton invoice form, a half-hydrated payment panel, or a toast that never confirms – and still count as a successful page load or HTTP 200. Client-side rendering and heavier report or payroll grids sit after the network already said OK. An HTTP generator that hammers login times the front door, not the freelancer workflow.

A green Wave status page is useful. It is not the same as “the invoice is ready.”

If Wave is opened inside Citrix, Microsoft RDS, AVD, or other cloud VDI, the split doubles: protocol green still is not Wave UI ready. ICA/HDX or RDP can stream a spinning browser while invoicing or payroll is still hydrating. Host CPU and broker tiles do not close a “Wave is slow” ticket. Use the Citrix, RDS, and cloud VDI posts above for remoting.

Schematic: Wave uptime, HTTPS 200, and browser loaded do not equal on-the-glass ready states for dashboard, invoice, payment, and report or payroll.
Schematic from this article: uptime/HTTP health versus glass time. Not a customer dashboard and not a measured Wave tenant.

Left stack is what uptime, HTTPS, and the browser document path see. Right stack is what freelancers and bookkeepers wait on. Only the glass stack is Wave response time as a person experiences it.

Which Wave steps to time

Write the steps before you pick a tool. Four intervals cover most UX arguments on Wave accounting, invoicing, payments, and payroll:

  1. Sign-in to usable Wave dashboard / chrome – from credentials submitted (or SSO return) until usable Wave navigation is ready – menus, company context, no full-screen spinner. Not “the IdP redirected” or “the document loaded.”
  2. Create / send invoice (or estimate) to ready confirmation – from starting a new invoice or estimate (or Send) until that step’s ready state on glass – form usable, or sent/confirmation painted. Not “the route changed.”
  3. Payment / receive or online pay step to ready – from the click that starts record payment, receive, or online pay until that step’s ready confirmation on glass. Pin the ready image for your Wave build and branding.
  4. Report / books / payroll step to ready – from the click that starts a report, books view, or payroll step until results or confirmation paint – the step that often generates “still waiting” tickets at month-end or payday.

Pin the browser (or published-app / Workspace image if remoted), display scale, account branding, and ready baselines. A timer on a moving theme is a story, not a measurement. When Wave runs inside Citrix or other VDI, run a logon storm separately from density. Storm stresses login-to-shell; density stresses in-session Wave work on hosts that already have users.

Time it like a script, not a feeling

On a modern Wave web UI 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: dashboard chrome, invoice or estimate confirmation, payment ready, report or payroll 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 the Wave tenant. That is the core of on-the-glass APM.

Four-step Wave pipeline: StartTimer, WaitForImage, and StopTimer for dashboard, invoice, payment, and report or payroll click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for dashboard, invoice, payment, and report/payroll steps. Change the start action and the ready image. Keep the timer. Sister posts use the identical glass method for EHR, finance suites, consulting apps, and remoted desktops.

Stopwatch versus synthetic

A person with a stopwatch can time one invoice send on a quiet morning. That is a demo, not a measurement program. A one-off cannot give a tail, run at month-end or payday rush, hold concurrent freelancer-like sessions while timing a payment or payroll step, or attach a screenshot of the failed state. Means hide the damage until owners are already saying “Wave is slow.”

A synthetic does the same StartTimer – WaitForImage – StopTimer path as a real browser (or remoted client), on a schedule or under load, with the same dashboard, invoice, payment, and report/payroll ready baselines – continuous on-the-glass monitoring, or a 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 language (schematic only – not a customer dataset or Wave SLA): sign-in to usable dashboard at p95 inside budget; create/send invoice ready at p95; payment/receive inside budget at p95; report/books/payroll ready 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 dashboard – invoice – payment – report/payroll, ramp concurrent freelancer-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 steps, every N minutes, with alerts and screenshots when glass time slips. See CitraTest APM.

The lab answers how many good concurrent Wave workflows fit before click-to-ready breaks. The watch answers whether today’s invoice and payroll steps are still inside the line. Do not use a load-test generator as your only production monitor. No agents inside the Wave tenant – each virtual user is another browser (or remoted session) driving the UI like a person.

What this is not

  • It is not a Wave SLA claim, uptime scorecard, or substitute for Wave status pages. Keep those for service reachability.
  • 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 Wave is covered.” Accounting, invoice, payment, and payroll GUIs are pixels users wait on, not only traces.
  • It is not a claim about Wave proprietary internals, unpublished SLAs, or mobile-app private APIs – only delivered UI readiness on the glass.
  • It is not a promise that last month’s number survives a UI redesign, new branding, browser update, or a move into Citrix / RDS / AVD. Re-time the glass when the image changes.

Take the interval users already wait

Wave response time is click-to-ready on the glass: dashboard, invoice, payment, and report/books/payroll ready – not a green status tile or HTTP 200. Time the steps that generate tickets when Wave is “up” but the invoice is not ready. 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 Wave tenant – real browser or remoted client, image and OCR, StartTimer to StopTimer for Wave – schedule a demo. Product pages: on-the-glass APM, CitraTest VU, and CitraTest APM.

Wave is a trademark of its respective owners. Citrix and related marks are trademarks of their respective owners. Tevron is not affiliated with Wave or those vendors. Names are used for identification only.

Cutover Tickets Start Where PMO Dashboards Stop

Posted on by
Cutover Tickets Start Where PMO Dashboards Stop
Tevron editorial illustration: The program dashboard is green. The published app is still spinning.

The program dashboard is green. The published app is still spinning. PMO status says on track. CDN and API checks returned 200. Protocol tiles for Citrix or AVD look healthy. Consultants and client users are still waiting for SAP, Oracle, Workday, or a custom portal to paint. That is the Deloitte-related response-time problem: program and infra green is not the wait delivery teams feel on screen.

Direct answer: Measure response time for the applications and virtual desktops that matter in Deloitte-led transformations and day-to-day consulting delivery – from what users see on screen (on the glass) – not only from program dashboards, PMO status, CDN or API 200s, or protocol health tiles. Time the interval from a click or key until the expected UI is visible: login-to-usable shell or desktop, published-app or portal ready, key business transaction click-to-ready (for example an SAP, Oracle, or Workday step), and report/export or handoff ready. That interval is click-to-ready – the number a delivery lead, client IT, and help desk can share.

Deloitte is a global network of member firms spanning audit, tax, consulting, advisory, and digital (firm context: Deloitte / Deloitte US). Tevron is not affiliated with Deloitte; Deloitte is a trademark of its respective owners. This article is not about timing Deloitte as a product – it is about timing the enterprise apps and VDI sessions that matter when Deloitte leads or supports a transformation. Sister glass methods: Citrix, RDS, cloud VDI, Epic, Oracle Health / Cerner, and Remedly. Method framing: on-the-glass APM, CitraTest VU, and CitraTest APM.

Why a green program or protocol tile is not “ready”

Transformation programs report milestones, RAID items, and cutover checklists. SaaS and custom portals sit behind HTTPS, CDNs, identity providers, and browsers. Citrix and AVD publish apps and desktops behind ICA/HDX or RDP. Uptime pages, URL checks, API latency, PMO dashboards, and protocol tiles tell you the program is tracking and the service or session broker is up. They are not a stopwatch for “the published app painted,” “the Workday step confirmed,” or “the SAP transaction is usable.”

A Workspace window can stream a spinner, a skeleton portal, a half-hydrated Oracle form, or a toast that never confirms – and still count as a successful launch or HTTP 200. Client-side rendering and heavy ERP transactions sit after the network and broker already said OK. An HTTP generator that hammers login times the front door, not the consulting workflow.

A green program dashboard is useful. It is not the same as “the published app appeared.”

When SAP, Oracle, Workday, or a custom portal runs inside Citrix, Microsoft RDS, AVD, or other cloud VDI, the split doubles: protocol green still is not UI ready. HDX or RDP can stream a spinning shell while the business app is still hydrating. Host CPU and broker tiles do not close a “the app is slow” ticket during a Deloitte-led go-live. Use the Citrix, RDS, and cloud VDI posts above for remoting.

Schematic: green PMO, CDN/API 200, and Citrix/AVD protocol tiles do not equal on-the-glass ready states for shell, published app, SAP/Oracle/Workday transaction, and handoff.
Schematic from this article: program/protocol health versus glass time. Not a customer dashboard and not a measured engagement.

Left stack is what PMO, CDN/API, and remoting health see. Right stack is what consultants and client users wait on. Only the glass stack is response time as a person experiences it in Deloitte-related delivery.

Which steps to time in Deloitte-led work

Write the steps before you pick a tool. Four intervals cover most UX arguments on published apps, portals, and remoted desktops in transformation and consulting delivery:

  1. Sign-in to usable shell / desktop – from credentials submitted (or SSO return) until a usable Workspace, desktop, or portal chrome is ready – menus, no full-screen spinner. Not “the IdP redirected” or “the broker session started.”
  2. Published app / portal ready – from launching the published SAP, Oracle, Workday, or custom portal until that app’s home or landing UI is interactive. Not “the icon flashed” or “the process started.”
  3. Key business transaction – from the click that starts a representative SAP, Oracle, or Workday step (or a custom portal transaction) until that step’s ready state on glass. Pin the ready image for the engagement’s build.
  4. Report / export / handoff – from the click that starts a report, export, or handoff step until results or confirmation paint – the step that often generates “still waiting” tickets at cutover.

Pin the browser or published-app / Workspace image, display scale, tenant branding, and ready baselines. A timer on a moving theme is a story, not a measurement. When work runs inside Citrix or other VDI, run a logon storm separately from density. Storm stresses login-to-shell; density stresses in-session SAP / Oracle / Workday work on hosts that already have users.

Time it like a script, not a feeling

On modern ERP and HCM UIs there is often no reliable DOM event that means “done” – and inside a remoted published app 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: shell chrome, published-app home, transaction confirmation, report or export result.
  • 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 SAP, Oracle, Workday, or the portal. That is the core of on-the-glass APM.

Four-step consulting transformation pipeline: StartTimer, WaitForImage, and StopTimer for shell, published app, SAP/Oracle/Workday transaction, and report or handoff click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for shell, published app, key transaction, and handoff steps. Change the start action and the ready image. Keep the timer. Sister posts use the identical glass method for EHR and remoted desktops.

Stopwatch versus synthetic

A person with a stopwatch can time one published-app launch on a quiet morning. That is a demo, not a measurement program. A one-off cannot give a tail, run at cutover rush, hold concurrent consultant-like sessions while timing a Workday or SAP step, or attach a screenshot of the failed state. Means hide the damage until delivery is already saying “the app is slow.”

A synthetic does the same StartTimer → WaitForImage → StopTimer path as a real browser or remoted Workspace / Remote Desktop client, on a schedule or under load, with the same shell, published-app, transaction, and handoff-ready baselines – continuous on-the-glass monitoring, or a 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 Deloitte SLA): sign-in to usable shell at p95 inside budget; published app ready at p95; key SAP / Oracle / Workday transaction 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 shell → published app → key transaction → handoff, ramp concurrent consultant-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 steps, every N minutes, with alerts and screenshots when glass time slips. See CitraTest APM.

The lab answers how many good concurrent transformation workflows fit before click-to-ready breaks. The watch answers whether today’s published app and transaction steps are still inside the line. Do not use a load-test generator as your only production monitor. No agents inside the client’s SAP, Oracle, Workday, or portal tenant – each virtual user is another consultant or client browser (or remoted session) driving the UI like a person.

What this is not

  • It is not a Deloitte SLA claim, engagement scorecard, or substitute for PMO program metrics. Keep RAID, milestones, and status for the program office.
  • 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 the engagement apps are covered.” Published-app and ERP GUIs are pixels users wait on, not only traces.
  • It is not a claim about Deloitte proprietary methods, unpublished client contracts, or SAP / Oracle / Workday internals – only delivered UI readiness on the glass.
  • It is not a promise that last month’s number survives a UI redesign, new published-app image, browser update, or a move into Citrix / RDS / AVD. Re-time the glass when the image changes.

Take the interval users already wait

Deloitte-related response time – for the apps and desktops that matter in Deloitte-led work – is click-to-ready on the glass: shell, published app, key transaction, and handoff ready – not a green program dashboard or protocol tile. Time the steps that generate tickets at cutover and in day-to-day consulting delivery. 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 client tenant – real browser or remoted client, image and OCR, StartTimer to StopTimer for the apps that matter in Deloitte engagements – schedule a demo. Product pages: on-the-glass APM, CitraTest VU, and CitraTest APM.

Deloitte is a trademark of its respective owners. SAP, Oracle, Workday, Citrix, and related marks are trademarks of their respective owners. Tevron is not affiliated with Deloitte or those vendors. Names are used for identification only.

Sage Spinners Don’t Belong in Month-End Close

Posted on by
Sage Spinners Don’t Belong in Month-End Close
Tevron editorial illustration: The API returned 200. The invoice screen is still spinning.

The API returned 200. The invoice screen is still spinning. CDN cache is warm. Browser RUM says the document loaded. Finance and ops staff are still waiting for the ledger to paint and payroll to confirm. That is the Sage response-time problem: SaaS or protocol health is not the wait the business feels.

Direct answer: Measure Sage – accounting, ERP, and payroll products including Sage Intacct, Sage X3, and Sage 50cloud / 200-class desktop and cloud accounting – response time from what finance and ops 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 Sage UI is visible: login-to-home, ledger / GL ready, AP / AR invoice or payment step, report / dashboard / payroll run ready. That interval is click-to-ready – the number a controller, help desk, and IT vendor can share.

Sage is business management software for accounting, people, payroll, and payments (product context: Sage). Browser Intacct / cloud suites and thick-client or remoted desktop apps still paint a GUI. Sister glass methods: Remedly, Epic, Oracle Health / Cerner, plus Citrix, RDS, and cloud VDI. Method framing: on-the-glass APM. This article times Sage itself.

Why a green SaaS tile is not “Sage is ready”

Cloud and hybrid finance suites sit behind HTTPS, CDNs, identity providers, browsers, and often Citrix, Microsoft RDS, or AVD. 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 company home painted,” “the journal entry opened,” or “payroll confirmed.”

A tab can show a spinner, a skeleton ledger, a half-hydrated AP form, or a toast that never confirms – and still count as a successful page load. Client-side rendering and heavy report grids sit after the network already said OK. An HTTP generator that hammers login times the front door, not the workflow.

A 200 from the API is useful. It is not the same as “the invoice screen appeared.”

If Sage is opened inside Citrix, Microsoft RDS, AVD, or other cloud VDI, the split doubles: protocol green still is not Sage UI ready. ICA/HDX or RDP can stream a spinning browser or thick client while the ledger is still hydrating. Host CPU and broker tiles do not close a “Sage is slow” ticket. Use the Citrix, RDS, and cloud VDI posts above for remoting.

Schematic: green CDN, API 200, RUM, and protocol tiles do not equal Sage UI-ready states for home, GL, AP/AR, and payroll on the glass.
Schematic from this article: network/HTTP/SaaS health versus glass time. Not a customer dashboard and not a measured finance org.

Top row is what network, CDN, API, RUM, and remoting health see. Bottom strip is what finance and ops staff wait on. Only the glass strip is Sage response time as a person experiences it.

Which Sage steps to time

Write the steps before you pick a tool. Four intervals cover most finance UX arguments on browser Intacct / cloud and thick-client or remoted desktop sessions:

  1. Sign-in to usable home / company – from credentials submitted (or SSO return) until usable Sage navigation is ready – company context, menus, no full-screen spinner. Not “the IdP redirected” or “the document loaded.”
  2. GL / ledger / journal entry ready – from opening the general ledger or starting a journal entry until the form and controls are usable. Not “the route changed.”
  3. AP / AR invoice or payment step – from open invoice, vendor bill, customer invoice, or payment action until that step’s ready state on glass. Pin the ready image for your product (Intacct, X3, 50cloud / 200-class).
  4. Report / dashboard / payroll run – from the click that starts a financial report, dashboard refresh, or payroll run step until results or confirmation paint.

Pin the browser or thick-client build (or published-app / Workspace image if remoted), display scale, company branding, and ready baselines. A timer on a moving theme is a story, not a measurement. When Sage runs inside Citrix or other VDI, run a logon storm separately from density. Storm stresses login-to-shell; density stresses in-session Sage work on hosts that already have users.

Time it like a script, not a feeling

On a modern cloud finance UI there is often no reliable DOM event that means “done” – and inside a remoted browser or thick client 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, ledger, invoice step, report or payroll 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 Sage. That is the core of on-the-glass APM.

Four-step finance waterfall: StartTimer, WaitForImage, and StopTimer for Sage sign-in, GL, AP/AR, and payroll or report click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for sign-in, GL, AP/AR, and report / payroll steps. Change the start action and the ready image. Keep the timer. Sister posts use the identical glass method for EHR and remoted desktops.

Stopwatch versus synthetic

A person with a stopwatch can time one Sage invoice open on a quiet morning. That is a demo, not a measurement program. A one-off cannot give a tail, run at month-end close, hold concurrent sessions while timing payroll, or attach a screenshot of the failed state. Means hide the damage until finance is already saying “Sage is slow.”

A synthetic does the same StartTimer → WaitForImage → StopTimer path as a real browser or remoted Workspace / Remote Desktop client, on a schedule or under load, with the same home, ledger, invoice, and payroll-ready baselines – continuous on-the-glass monitoring, or a Sage 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 Sage SLA): sign-in to usable home at p95 inside budget; GL ready at p95; open AP invoice and payroll step 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 → GL → AP/AR → report / payroll, 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 Sage steps, every N minutes, with alerts and screenshots when glass time slips. See CitraTest APM.

The lab answers how many good concurrent Sage workflows fit before click-to-ready breaks. The watch answers whether today’s ledger and invoice steps are still inside the line. Do not use a load-test generator as your only production monitor. No agents inside Sage’s cloud or desktop binaries – 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 Sage is covered.” Ledger and invoice GUIs are pixels staff wait on, not only traces.
  • It is not a claim about Sage 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 company theme, browser or thick-client update, or a move into Citrix / RDS / AVD. Re-time the glass when the image changes.

Take the interval staff already wait

Sage response time is click-to-ready on the glass – home, ledger, AP/AR, and report / payroll ready – not a green CDN or protocol tile. Time sign-in, GL, invoice / payment, and payroll 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 Sage tenant or desktop install – real browser or remoted client, image and OCR, StartTimer to StopTimer for Sage – schedule a demo. Product pages: on-the-glass APM, CitraTest VU, and CitraTest APM.

Sage, Sage Intacct, Sage X3, Sage 50cloud, and related marks are trademarks of The Sage Group plc or its affiliates. Tevron is not affiliated with Sage. Product names are used for identification only.

Remedly Visit Speed: Click-to-Ready for Clinics

Posted on by
Remedly Visit Speed: Click-to-Ready for Clinics
Tevron editorial illustration: The page can return 200. Remedly is still waiting.

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.

Two-column schematic: network, HTTP, CDN, and SaaS health timers versus on-the-glass Remedly UI-ready click-to-ready for the same staff workflow.
Schematic from this article: network/HTTP/SaaS health versus glass time. Not a customer dashboard and not a measured practice.

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:

  1. 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.”
  2. Schedule / practice-management ready – from opening the calendar or front-desk view until appointments and controls are usable. Not “the route changed.”
  3. 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.
  4. 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.

Three-row schematic of StartTimer, WaitForImage, and StopTimer for Remedly sign-in, schedule ready, and encounter or RCM click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

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.

PowerChart Ready Beats Protocol Ready

Posted on by
PowerChart Ready Beats Protocol Ready
Tevron editorial illustration: Director can look fine. PowerChart is still waiting.

Director says ICA RTT is fine. StoreFront returned 200. The VDA is green. The nurse is still waiting for the chart. That is the Oracle Health (Cerner) response-time problem: remoting health is not the wait the clinician feels.

Direct answer: Measure Oracle Health / Cerner – for example PowerChart or other Millennium clinical GUI – response time from what the clinician sees on screen – on the glass – not only from Citrix HDX/ICA counters, RDP latency, Workspace or portal HTTP, or host CPU. Time the interval from a click or key until the expected EHR screen state is visible. That interval is click-to-ready – the number a CAB, help desk, and clinical informatics can share.

Oracle Health (the former Cerner business) is the EHR and application layer – product context: Oracle Health. Citrix, Microsoft RDS, AVD, and other VDI stacks deliver the pixels. Hospitals often run Epic and Oracle Health side by side; the glass method is the same. Sibling page: Epic / EHR on the glass. Sister posts: Epic, Citrix, RDS, and cloud VDI. Load-test method: How to load test Citrix and How to load test Citrix Virtual Apps and Desktops. This article times Oracle Health / Cerner itself.

Why a green Director tile is not “the chart appeared”

HDX, ICA, RDP, and cloud remoting move pixels out and keyboard and mouse in. Director, Monitor, broker health, and host CPU tell you the session is up and the channel is healthy. They are not a stopwatch for “PowerChart painted” or “the chart is ready.”

A session can stream a logon animation, a spinning cursor, or a half-drawn Millennium window and still look connected. Profile attach, GPO, FSLogix (or equivalent), and the EHR client sit after remoting is already up. StoreFront, Workspace, and hospital portals are websites – an HTTP generator times the store, not the chart.

A green Director tile is useful. It is not the same as “the chart appeared.”

Host CPU can sit at 40 percent while login-to-shell stretches and PowerChart paints late. Protocol RTT can look fine while open-chart stalls. Green remoting tiles do not close a “Cerner is slow” ticket.

Two-column schematic: broker, protocol, and host timers versus on-the-glass Oracle Health / Cerner chart-ready click-to-ready for the same session.
Schematic from this article: broker/protocol/host versus glass time. Not a customer dashboard and not a measured farm.

Left column is what broker, protocol, and host timers see. Right column is what the clinician waits on – Oracle Health / Cerner response time as a person experiences it.

Which Oracle Health / Cerner steps to time

Write the steps before you pick a tool. Three intervals cover most clinical UX arguments on published apps and remoted desktops:

  1. Logon-to-shell – from credentials submitted (or Workspace / StoreFront / Gateway / portal launch) until a usable desktop or published-app window is ready: shell, icons, no logon animation. Not “the broker returned a session.”
  2. Oracle Health / published-app launch – from the icon or Start-menu click until first usable paint of PowerChart or the Millennium clinical GUI you publish. Not “the process started on the VDA or Session Host.”
  3. In-session transactions – from the click or key that starts the work until ready: open chart or record, search, save, switch activity. This is the wait behind “Cerner is slow” tickets after clinicians are already in session.

Pin the image, VDA or Session Host SKU, Workspace or Remote Desktop client, StoreFront / Gateway / portal build, and the published Oracle Health / Cerner resource. A timer on a moving image is a story, not a measurement.

For capacity work, run a logon storm separately from density. Storm stresses login-to-shell; density stresses in-session chart and search on hosts that already have clinicians. Blending them hides which interval broke.

Time it like a script, not a feeling

On remoted Oracle Health / Cerner there is no DOM event that means “done.” The practical signal is the bitmap. The measurement pattern is the same one CitraTest has used for years on published EHR GUIs:

  • StartTimer when the user action happens – submit, Workspace launch, click, or key.
  • WaitForImage until a baseline of the ready state is visible: the shell, the PowerChart / Millennium window, the chart.
  • 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 on the VDA. That is the core of on-the-glass APM.

Three-row schematic of StartTimer, WaitForImage, and StopTimer for Oracle Health / Cerner logon-to-shell, PowerChart / Millennium launch, and chart-ready click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for login, EHR launch, and in-session chart work. Change the start action and the ready image. Keep the timer. The Epic sister post uses the identical glass method for Hyperspace / Hyperdrive when the same team supports both EHRs.

Stopwatch versus synthetic

A person with a stopwatch can time one PowerChart logon on a quiet morning. That is a demo, not a measurement program. A one-off cannot give a tail, run at shift change every weekday, hold concurrent sessions while timing open-chart, or attach a screenshot of the failed state. Means hide the damage until the desk is taking “Cerner is slow” calls.

A synthetic does the same StartTimer -> WaitForImage -> StopTimer path as a real Workspace or Remote Desktop client, on a schedule or under load, with the same PowerChart / Millennium and chart-ready baselines. That is on-the-glass monitoring when it runs continuously, and an Oracle Health-on-Citrix (or RDS / AVD) load test when it ramps users.

If you only have a stopwatch, use it to write the acceptance line – then automate it. Example capacity-plan language (schematic only – not a customer dataset or Oracle/Cerner SLA): logon-to-shell 45 seconds at p95 and 60 at p99; EHR published-app open 8 seconds at p95; open-chart inside the written budget at p95; fewer than 1 percent of runs fail, disconnect, or hang.

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. Freeze the image, walk the real StoreFront / Workspace / Gateway path into published PowerChart or Millennium, run storm and sustain as separate shapes, stop at the written budget. See CitraTest VU load testing.
  • CitraTest APM watches production. The same login -> EHR -> open-chart steps, every N minutes, with alerts and screenshots when glass time slips. See CitraTest APM.

The lab answers how many good Oracle Health / Cerner sessions fit on this SKU. The watch answers whether today’s logon-to-shell and open-chart are still inside the SLA. Do not use a load-test generator as your only production monitor, or treat a single synthetic as a density number. No agents on VDAs, Session Hosts, or brokers – each virtual user or monitor is another Workspace or Remote Desktop session launching the EHR like a clinician.

What this is not

  • It is not a replacement for Director, Monitor, HDX Insights, RD Connection Broker health, or AVD host metrics. Keep those for the remoting path.
  • It is not an HTTP soak of StoreFront, Workspace, Gateway, or the hospital portal. Keep that for the front door.
  • It is not “we have full-stack APM, so Oracle Health is covered.” Published PowerChart and Millennium GUIs are pixels, not traces.
  • It is not a claim about Oracle Health or Cerner proprietary metrics, internal tooling, or customer SLAs – only delivered session UX on Citrix, RDS, AVD, and peers, on the glass.
  • It is not a promise that last quarter’s number survives a new VDA image, FSLogix policy, Millennium / PowerChart build, or a move to DaaS / AVD. Re-time the glass when the image changes.

Take the interval clinicians already wait

Oracle Health / Cerner response time is click-to-ready on the glass – PowerChart or Millennium chart ready, not a green protocol tile. Time logon-to-shell, EHR published-app launch, and the in-session steps that generate tickets. Separate logon storm from density. Use a stopwatch only to write the line; use a synthetic to keep it: CitraTest VU under load, CitraTest APM every shift.

When you need that path without agents on the farm – real client, image and OCR, StartTimer to StopTimer for Oracle Health / Cerner – schedule a demo. Product pages: Epic / EHR on the glass, on-the-glass APM, CitraTest VU, and CitraTest APM.

The Chart Has to Appear: Epic Response Time on the Glass

Posted on by
The Chart Has to Appear: Epic Response Time on the Glass
Tevron editorial illustration: HDX can look fine. The chart is still waiting.

Director says ICA RTT is fine. StoreFront returned 200. The VDA is green. The nurse is still waiting for the chart. That is the Epic response-time problem in one sentence: remoting health is not the wait the clinician feels.

Direct answer: Measure Epic — Hyperspace or Hyperdrive — response time from what the clinician sees on the screen — on the glass — not only from Citrix HDX/ICA counters, RDP latency, StoreFront or Workspace HTTP, or host CPU. Time the interval from a click or key until the expected Epic screen state is visible. That interval is click-to-ready. It is the number a CAB, a help desk, and clinical informatics can share.

Epic is the EHR and application layer. Citrix, Microsoft RDS, AVD, and other VDI stacks deliver the pixels. Product context: Epic / EHR on the glass. Sister posts on the same glass clock: Citrix, RDS, and cloud VDI response time. Load-test method: How to load test Citrix and How to load test Citrix Virtual Apps and Desktops. This article is narrower: how to time Epic itself.

Why a green Director tile is not “the chart appeared”

HDX, ICA, RDP, and cloud remoting protocols move pixels out and keyboard and mouse in. Director, Monitor, broker health, and host CPU are good at telling you the session is up and the channel is healthy. They are not a stopwatch for “Hyperspace painted” or “the chart is ready.”

A session can stream a logon animation, a spinning cursor, or a half-drawn Epic window and still look connected. Profile attach, GPO, FSLogix (or equivalent), and the EHR client itself sit after remoting is already up. StoreFront and Workspace are websites. Hammering them with an HTTP generator times the store, not the chart.

A green Director tile is useful. It is not the same as “the chart appeared.”

Host CPU can sit at 40 percent while login-to-shell stretches and Hyperdrive paints late. Protocol RTT can look fine while open-chart stalls. Green remoting tiles do not close an “Epic is slow” ticket.

Two-column schematic: broker, protocol, and host timers versus on-the-glass Epic chart-ready click-to-ready for the same session.
Schematic from this article: broker/protocol/host versus glass time. Not a customer dashboard and not a measured farm.

Left column is what broker, protocol, and host timers see. Right column is what the clinician waits on. Only the right column is Epic response time as a person experiences it.

Which Epic steps to time

Write the steps before you pick a tool. Three intervals cover most Epic UX arguments on published apps and remoted desktops:

  1. Logon-to-shell — from credentials submitted (or the Workspace / StoreFront / Gateway / portal launch) until a usable desktop or published-app window is ready: shell, icons, no logon animation. Not “the broker returned a session.”
  2. Epic / published-app launch — from the icon or Start-menu click until first usable paint of Hyperspace or Hyperdrive. Not “the process started on the VDA or Session Host.”
  3. In-session transactions — from the click or key that starts the work until the ready state: open chart, search, save, switch activity. This is the wait that generates “Epic is slow” tickets after everyone is already in session.

Pin the image, VDA or Session Host SKU, Workspace or Remote Desktop client, StoreFront / Gateway / portal build, and the published Epic resource. A timer on a moving image is a story, not a measurement.

For capacity work, run a logon storm separately from density. Storm stresses login-to-shell. Density stresses in-session chart and search work on hosts that already have clinicians. Blending them hides which interval broke.

Time it like a script, not a feeling

On remoted Epic there is no DOM event that means “done.” The practical signal is the bitmap. The measurement pattern is the same one CitraTest has used for years on published EHR GUIs:

  • StartTimer when the user action happens — submit, Workspace launch, click, or key.
  • WaitForImage until a baseline of the ready state is visible: the shell, the Hyperspace or Hyperdrive window, the chart.
  • 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. You do not install an agent on the VDA to learn that. That is the core of on-the-glass APM.

Three-row schematic of StartTimer, WaitForImage, and StopTimer for Epic logon-to-shell, Hyperspace/Hyperdrive launch, and chart-ready click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for login, Epic launch, and in-session chart work. Change the start action and the ready image. Keep the timer.

Stopwatch versus synthetic

A person with a stopwatch can time one Epic logon on a quiet morning. That is a demo, not a measurement program.

A one-off cannot give you a tail, run at shift change every weekday, hold concurrent published-app sessions while timing open-chart, or attach a screenshot of the failed state. Means hide the damage until the service desk is already taking “Epic is slow” calls.

A synthetic does the same StartTimer → WaitForImage → StopTimer path as a real Workspace or Remote Desktop client, on a schedule or under load, with the same Hyperspace, Hyperdrive, and chart-ready baselines. That is on-the-glass monitoring when it runs continuously, and an Epic-on-Citrix (or RDS / AVD) load test when it ramps concurrent users.

If you only have a stopwatch, use it to write the acceptance line — then automate the line. Example language teams already put on capacity plans (schematic only, not a customer dataset): logon-to-shell 45 seconds at p95 and 60 seconds at p99; Epic published-app open 8 seconds at p95; open-chart inside the written budget at p95; fewer than 1 percent of runs fail, disconnect, or hang.

Continuous watch versus load test

On-the-glass is an idea, not a product SKU. Two jobs share the path for Epic:

  • CitraTest VU load-tests capacity. Freeze the image, walk the real StoreFront / Workspace / Gateway path into published Epic, run storm and sustain as separate shapes, stop at the written budget. That is the concurrent-clinician number a CAB can defend. See CitraTest VU load testing.
  • CitraTest APM watches production. The same login → Epic → open-chart steps, every N minutes, with alerts and screenshots when glass time slips. That is the morning watch after go-live or an image change. See CitraTest APM.

The lab answers “how many good Epic sessions fit on this SKU.” The watch answers “is today’s logon-to-shell and open-chart still inside the SLA.” Do not use a load-test generator as your only production monitor, and do not treat a single synthetic as a density number.

No agents on the VDAs, Session Hosts, or brokers are required for that path. Each virtual user or monitor is another Workspace or Remote Desktop session launching Epic like a clinician. If the generator desktop is pegged, you are measuring the lab, not the farm.

What this is not

  • It is not a replacement for Director, Monitor, HDX Insights, RD Connection Broker health, or AVD host metrics. Keep those for the remoting path.
  • It is not an HTTP soak of StoreFront, Workspace, or Gateway. Keep that for the front door.
  • It is not “we have full-stack APM, so Epic is covered.” Published Hyperspace and Hyperdrive GUIs are pixels, not traces.
  • It is not a claim about Epic’s internal tooling or proprietary metrics — only the delivered session UX on Citrix, RDS, AVD, and peers, on the glass.
  • It is not a promise that last quarter’s number survives a new VDA image, FSLogix policy, Hyperdrive build, or a move to DaaS / AVD. Re-time the glass when the image changes.

Take the interval clinicians already wait

Epic response time, as a clinician experiences it, is click-to-ready on the glass — Hyperspace or Hyperdrive chart ready, not a green protocol tile. Time logon-to-shell, Epic published-app launch, and the in-session steps that generate tickets. Separate logon storm from density. Use a stopwatch only to write the line. Use a synthetic to keep the line: CitraTest VU under load, CitraTest APM every shift.

When you need that path without agents on the farm — real Workspace or Remote Desktop client, image and OCR, StartTimer to StopTimer for Epic — schedule a demo. Product pages: Epic / EHR on the glass, CitraTest VU, and CitraTest APM.

Autoscale Hides Density Problems. Glass Time Doesn’t

Posted on by
Autoscale Hides Density Problems. Glass Time Doesn’t
Tevron editorial illustration: The broker can look fine. The glass is still waiting.

Cloud ops says the Workspace URL returned 200. The DaaS or AVD broker assigned a session. Protocol RTT looks fine. The nurse is still waiting for the chart. That is the cloud VDI response-time problem in one sentence: control-plane health is not the wait the user feels.

Direct answer: Measure Citrix DaaS, Azure Virtual Desktop (AVD), Windows 365, and other cloud-hosted virtual apps and desktops from what the user sees on the screen — on the glass — not only from Workspace URL HTTP, broker health, or protocol RTT. Time the interval from a click or key until the expected screen state is visible. That interval is click-to-ready — the number a CAB and a help desk can share.

The sibling method for walking a real cloud path under load is in How to load test cloud virtual apps and desktops. Tooling context: best cloud load testing tools. Sister posts on the same glass clock: Citrix response time and RDS response time. This article is narrower: how to time the wait when the broker is in the cloud and the pixels live in a resource location.

Why the control plane can look fine while users wait

In cloud VDI the front door and the pixels are not the same machine. Workspace (or the AVD / Windows 365 portal) is a website and a control plane. The broker assigns a session to a resource location — a host pool, a delivery group, a Cloud PC. Portal HTTP, broker assignment, and protocol RTT tell you the channel is up. They are not a stopwatch for “the published app painted.”

A session can stream a logon animation, a spinning cursor, or a half-drawn shell and still look connected. Profile attach, GPO, FSLogix (or equivalent), and the line-of-business app itself sit after remoting is already up. Hammering the Workspace URL with an HTTP generator times the store, not the session host.

Broker green is useful. It is not the same as “the shell appeared.”

Autoscale makes the split easier to miss. When hosts come and go, average density can look comfortable while some users sit on a hot host or wait through a cold start. Autoscale can hide density problems; it does not remove them. Green control-plane tiles do not close a “cloud desktop is slow” ticket.

Two-column schematic: cloud control-plane, broker, and network timers versus on-the-glass click-to-ready for the same cloud VDI session.
Schematic from this article: control plane versus glass time. Not a customer dashboard and not a measured farm.

Left column is what control-plane, broker, and network timers see. Right column is what the user waits on. Only the right column is cloud VDI response time as a person experiences it.

Which steps to time

Write the steps before you pick a tool. Three intervals cover most cloud VDI UX arguments — Citrix DaaS, AVD, Windows 365, or another hosted desktop:

  1. Logon-to-shell — from credentials submitted (or the Workspace / portal / Gateway launch) until a usable desktop or published-app window is ready: shell, icons, no logon animation. Not “the broker returned a session.”
  2. Published app / RemoteApp launch — from the icon or Start-menu click until first paint of the business app: Epic, SAP, Outlook, the line-of-business client. Not “the process started on the session host.”
  3. In-session transactions — from the click or key that starts the work until the ready state: search, open the record, save, print, switch published apps. This is the wait that generates “the cloud desktop is slow” tickets after everyone is already in session.

Pin the image, resource-location SKU, client (Workspace app, Remote Desktop client, or Windows 365), portal or Gateway build, and the published resource. A timer on a moving image is a story, not a measurement.

For capacity work, run a logon storm separately from density. Storm stresses login-to-shell — including cold starts when autoscale brings hosts online. Density stresses in-session transactions on hosts that already have users. Blending them hides which interval broke.

Time it like a script, not a feeling

On remoted cloud desktops there is no DOM event that means “done.” The practical signal is the bitmap. The measurement pattern is the same one CitraTest has used for years on published apps — and it applies whether the pixels come from DaaS, AVD, or Windows 365:

  • StartTimer when the user action happens — submit, Workspace launch, click, or key.
  • WaitForImage until a baseline of the ready state is visible: the shell, the published or RemoteApp window, the chart.
  • 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. You do not install an agent on the session host or Cloud PC to learn that. That is the core of on-the-glass APM.

Three-row schematic of StartTimer, WaitForImage, and StopTimer for cloud VDI logon-to-shell, published/RemoteApp launch, and in-session click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for login, published/RemoteApp launch, and in-session work. Change the start action and the ready image. Keep the timer.

Stopwatch versus synthetic

A person with a stopwatch can time one Workspace logon on a quiet morning. That is a demo, not a measurement program. A one-off cannot give you a tail, run at 8:00 every weekday, hold concurrent sessions while autoscale adds hosts, or attach a screenshot of the failed state.

A synthetic does the same StartTimer → WaitForImage → StopTimer path as a real Workspace or Remote Desktop client, on a schedule or under load, with the same baseline images. That is on-the-glass monitoring when it runs continuously, and a cloud VDI load test when it ramps concurrent users.

If you only have a stopwatch, use it to write the acceptance line — then automate it. Example language (schematic only, not a customer dataset): logon-to-shell 45 seconds at p95 and 60 at p99; published-app open 8 seconds at p95; fewer than 1 percent of runs fail or hang. Re-check after an autoscale or image change.

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. Freeze the image, walk the real Workspace / portal / Gateway path into the resource location, run storm and sustain as separate shapes, stop at the written budget. That is the concurrent-user number a CAB can defend — including how autoscale behaves under a logon storm. See CitraTest VU load testing.
  • CitraTest APM watches production. The same login → published app → in-session steps, every N minutes, with alerts and screenshots when glass time slips. That is the morning watch after go-live to cloud. See CitraTest APM.

The lab answers “how many good sessions fit on this host-pool SKU.” The watch answers “is today’s logon-to-shell still inside the SLA.” Do not use a load-test generator as your only production monitor, and do not treat a single synthetic as a density number. No agents on session hosts or cloud brokers are required — each monitor is another Workspace or Remote Desktop session.

What this is not

  • It is not a replacement for Workspace health, DaaS / AVD / Windows 365 host metrics, or protocol Insights. Keep those for the control plane and remoting path.
  • It is not an HTTP soak of the Workspace URL or cloud portal. Keep that for the front door.
  • It is not “we have full-stack APM, so cloud VDI is covered.” Remoted GUIs are pixels, not traces.
  • It is not a promise that last quarter’s on-prem number survives a move to DaaS, AVD, or Windows 365 — or that last month’s number survives a new golden image or autoscale policy. Re-time the glass when the image or resource location changes.

Take the interval users already wait

Cloud VDI response time — Citrix DaaS, AVD, Windows 365, and peers — as a user experiences it, is click-to-ready on the glass. Separate the control plane from session pixels. Time logon-to-shell, published/RemoteApp launch, and the in-session steps that generate tickets. Use a stopwatch only to write the line. Use a synthetic to keep the line: CitraTest VU under load, CitraTest APM every shift.

When you need that path without agents on the resource location — real Workspace or Remote Desktop client, image and OCR, StartTimer to StopTimer — schedule a demo. Product pages: CitraTest VU and CitraTest APM.

Stop Timing RDP Latency. Start Timing the Shell

Posted on by
Stop Timing RDP Latency. Start Timing the Shell
Tevron editorial illustration: RDP can look fine. The glass is still waiting.

Ops says RDP latency is fine. The session is connected. RD Connection Broker handed out a Session Host. The clerk is still waiting for the desktop to finish painting. That is the Microsoft RDS response-time problem in one sentence: protocol health is not the wait the user feels.

Direct answer: Measure RDS response time from what the user sees on the screen — on the glass — not only from RDP round-trip, network latency, host CPU, or broker health. Time the interval from a click or key until the expected screen state is visible. That interval is click-to-ready. It is the number a CAB and a help desk can share.

This post is about Microsoft Remote Desktop Services (RDS) — Session Hosts, RemoteApp, RD Gateway / RD Web — not Amazon Relational Database Service. The sibling method for walking a real RDS path under load is in How to load test Microsoft RDS. Tooling context lives on best RDS load testing tools. This article is narrower: how to time the wait itself.

Why RDP can look fine while users wait

RDP is a remoting protocol. It moves pixels out and keyboard and mouse in. Performance Monitor counters, RD Connection Broker health, and “session connected” status are good at telling you the channel is up. They are not a stopwatch for “the published app painted.”

A session can stream a logon animation, a spinning cursor, or a half-drawn shell and still look connected. Profile attach, GPO, FSLogix (or equivalent), and the line-of-business app itself sit after RDP is already up. RD Web is a website. Hammering it with an HTTP generator times the portal, not the Session Host farm.

RDP round-trip is useful. It is not the same as “the shell appeared.”

The same glass-versus-protocol split shows up on Citrix farms — see the sister post How to measure Citrix response time. Host CPU can sit at 40 percent while login-to-shell stretches and the RemoteApp paints late. Green session tiles do not close that ticket.

Two-column schematic: RDP and session protocol timers versus on-the-glass click-to-ready for the same Microsoft RDS session.
Schematic from this article: protocol timers versus glass time. Not a customer dashboard and not a measured farm.

Left column is what protocol and host timers see. Right column is what the user waits on. Only the right column is RDS response time as a person experiences it.

Which steps to time

Write the steps before you pick a tool. Three intervals cover most RDS UX arguments:

  1. Logon-to-shell — from credentials submitted (or the RD Web / Gateway launch) until a usable desktop or RemoteApp window is ready: shell, icons, no logon animation. Not “the broker returned a session.”
  2. RemoteApp / published app launch — from the icon or Start-menu click until first paint of the business app: Epic, SAP, Outlook, the line-of-business client. Not “the process started on the Session Host.”
  3. In-session transactions — from the click or key that starts the work until the ready state: search, open the record, save, print, switch RemoteApps. This is the wait that generates “the desktop is slow” tickets after everyone is already in session.

Pin the image, Session Host SKU, client (mstsc / Remote Desktop app), RD Web or Gateway build, and the published collection. A timer on a moving image is a story, not a measurement.

For capacity work, run a logon storm separately from density. Storm stresses login-to-shell. Density stresses in-session transactions on hosts that already have users. Blending them hides which interval broke.

Time it like a script, not a feeling

On RDP there is no DOM event that means “done.” The practical signal is the bitmap. The measurement pattern is the same one CitraTest has used for years on remoted apps — including Citrix HDX farms — and it applies unchanged to Microsoft RDS:

  • StartTimer when the user action happens — submit, click, or key.
  • WaitForImage until a baseline of the ready state is visible: the shell, the RemoteApp window, the chart.
  • 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. You do not install an agent on the Session Host to learn that. That is the core of on-the-glass APM.

Three-row schematic of StartTimer, WaitForImage, and StopTimer for RDS logon-to-shell, RemoteApp launch, and in-session click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for login, RemoteApp launch, and in-session work. Change the start action and the ready image. Keep the timer.

Stopwatch versus synthetic

A person with a stopwatch can time one logon on a quiet morning. That is a demo, not a measurement program.

A one-off cannot give you a tail. It cannot run at 8:00 every weekday. It cannot hold two hundred sessions and still time open-record. It cannot attach a screenshot of the failed state. Means hide the damage until the service desk is already taking calls.

A synthetic does the same StartTimer → WaitForImage → StopTimer path as a real Remote Desktop client, on a schedule or under load, with the same baseline images. That is on-the-glass monitoring when it runs continuously, and an RDS load test when it ramps concurrent users.

If you only have a stopwatch, use it to write the acceptance line — then automate the line. Example language teams already put on capacity plans (schematic only, not a customer dataset): logon-to-shell 45 seconds at p95 and 60 seconds at p99; RemoteApp open 8 seconds at p95; fewer than 1 percent of runs fail, disconnect, or hang.

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. Freeze the image, walk the real RD Web / Gateway / mstsc path, run storm and sustain as separate shapes, stop at the written budget. That is the concurrent-user number a CAB can defend. See CitraTest VU load testing.
  • CitraTest APM watches production. The same login → RemoteApp → in-session steps, every N minutes, with alerts and screenshots when glass time slips. That is the morning watch after go-live. See CitraTest APM.

The lab answers “how many good sessions fit on this Session Host SKU.” The watch answers “is today’s logon-to-shell and open-record still inside the SLA.” Do not use a load-test generator as your only production monitor, and do not treat a single synthetic as a density number.

No agents on the Session Hosts or brokers are required for that path. Each virtual user or monitor is another Remote Desktop session. If the generator desktop is pegged, you are measuring the lab, not the farm.

What this is not

  • It is not a replacement for Performance Monitor, RD Connection Broker health, or Azure Virtual Desktop / Windows 365 host metrics. Keep those for the remoting and host path.
  • It is not an HTTP soak of RD Web or Gateway. Keep that for the front door.
  • It is not “we have full-stack APM, so RDS is covered.” Remoted GUIs are pixels, not traces.
  • It is not a promise that last quarter’s number survives a new Session Host image, profile policy, or a move to AVD. Re-time the glass when the image changes.

Take the interval users already wait

Microsoft RDS response time, as a user experiences it, is click-to-ready on the glass. Time logon-to-shell, RemoteApp launch, and the in-session steps that generate tickets. Use a stopwatch only to write the line. Use a synthetic to keep the line: CitraTest VU under load, CitraTest APM every shift.

When you need that path without agents on the farm — real Remote Desktop client, image and OCR, StartTimer to StopTimer — schedule a demo. Product pages: CitraTest VU and CitraTest APM.