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.
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:
- 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.”
- 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.”
- 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.
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.