Xero Was “Operational.” I Still Couldn’t Connect My AI Worker

I wanted to give my OpenClaw AI worker access to my Xero account so it could make authorized accounting changes for me. The first step was ordinary: open Xero’s developer portal, create an app, and obtain the credentials needed for the OAuth connection.

I could not get through the first step. The app-management flow stopped on a white card that said Redirecting… and stayed there.

This was a production outage for the task I needed to perform. It may not have affected Xero’s accounting API or every developer, but the distinction is not useful to the person staring at a spinner. The capability was unavailable.

The status page was green

At the same time, Xero’s public developer-platform status page reported all systems operational, including the Developer Centre, and showed no incident for the day. The screenshot and the green status page can both be true. They are measuring different things.

A service check can prove that a host responds. An API check can prove that one endpoint returns an expected status. Neither proves that a signed-in customer can cross several front ends, cookies, redirects, identity services, and browser-side scripts to complete a business task.

Uptime is not “the servers answered.” Uptime is “the customer could finish the job.”

Why extensive E2E coverage matters

Unit tests protect logic. Integration tests protect boundaries. End-to-end tests protect promises. A developer portal promises more than rendered HTML: authenticate, load the app list, create or manage an app, complete the redirect, and produce usable credentials.

That full journey should run before release against a production-like environment. It should cover the successful path, expired sessions, multiple redirect hops, third-party identity failures, cached and uncached browsers, and the browsers customers actually use. The assertions should target outcomes, not implementation details: the app-management screen becomes usable and a developer can complete the credential workflow.

E2E suites are slower and more fragile than unit tests, so they should not replace the lower layers. But deleting the last mile because it is inconvenient leaves the most valuable promise untested.

Then run the critical journeys in production

Pre-deployment testing still cannot reproduce production exactly. DNS, certificates, CDN rules, authentication tenants, feature flags, real cookies, data migrations, and third-party services can behave differently after deployment. The answer is a small set of synthetic users that exercise the highest-value journeys in production on a regular heartbeat.

That heartbeat should use a real browser, follow the same redirects, interact with the same controls, and verify the final state a person expects. It should run every few minutes from more than one location, retain screenshots and traces on failure, retry carefully to separate a transient network problem from a persistent defect, and alert someone who can act.

Use dedicated test accounts and reversible or isolated test data. Monitoring should never create surprise invoices, corrupt real books, or grant a synthetic user broad production privileges.

This is why I built StatusNest and AlertTray

StatusNest checks sites with a real Chromium browser rather than treating a successful HTTP response as proof that the experience works. AlertTray is the alerting side of the same operational idea: failures need to reach a human instead of disappearing into a dashboard nobody is watching.

The Xero screen is a compact example of the problem those products are meant to address. The page loaded. The network panel showed successful responses. A shallow monitor could remain green indefinitely. Only a journey-level assertion—the redirect completes and the app-management UI becomes usable—would catch what mattered.

Monitor capabilities, not just components

A useful production heartbeat can be written as a sentence a customer would say:

• I can sign in.
• I can open the developer app-management page.
• I can create or edit an integration.
• I can complete the authorization redirect.
• The resulting credentials can access the intended organization.

Those checks cross component boundaries by design. When one fails, traces, screenshots, console errors, and request timing help the team locate the component. The monitor’s first responsibility, though, is to detect that the customer promise is broken.

The cost of missing the last mile

This failure did not merely inconvenience a developer. It blocked an automation project. My OpenClaw could not receive the access it needed, so it could not do the Xero work I intended to delegate. One broken redirect stopped every capability downstream of it.

That is why critical-path E2E testing and production heartbeats deserve first-class treatment. Test the journey extensively before shipping. Repeat a safe version of it in production. Alert on the outcome. And define availability from the user’s side of the glass.