When Wave Is Up but the Invoice Isn’t Ready

Tevron editorial illustration: Wave status is green. The invoice UI is still spinning.
Editorial illustration for this article. Not a data chart.

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.