Skip to content
allanninal.dev/build
Collaborate

Part 2 of 7 · Uptime status poster series ~5 min read

How a journey check works

A ping tells you a server answered. A journey check tells you a customer could have done the thing they came to do. The second is much more useful and much more dangerous, because it involves actually doing things on your production system every minute forever.

Key takeaways

  • A journey check performs a real sequence and asserts on content, not just status codes.
  • Four journeys is usually enough: home, search, log in, and reach checkout.
  • A check account is a real account, marked as one, excluded from analytics and reporting.
  • The check never completes a purchase, sends a message or writes customer data.
  • Timing is recorded but a slow journey is not a down journey.

What a check asserts

journey     checkout
steps       GET  /                  200, contains ’Add to basket’
            POST /basket/add        302 or 200
            GET  /basket            200, contains the item name
            GET  /checkout          200, contains ’Payment’
stop        before submitting payment — always
assert      content, not just status
timeout     8s per step, 30s total
record      per-step timing, every run

The content assertions are what make this different from a ping. A checkout page that returns 200 and renders an error message is broken, and only a content assertion sees that. Asserting on a specific string is brittle in a useful way: when somebody changes the wording, the check fails, somebody updates it, and the check stays honest.

The four journeys

The four customer journeys worth checkingA vertical chain of five steps entered by a box labelled Which journeys, and not every page. Step one is Home loads, the cheapest signal. Step two is Search returns results, which exercises the database. Step three is Login succeeds, which exercises authentication and session handling. Step four is Checkout reaches payment, and stops there. Step five notes four checks across three regions, giving twelve runs a minute. A note says each journey exercises a different subsystem, which is how four is enough.AWS ACCOUNTWhich journeys?not every pageHome loadsthe cheapest signalSearch returns resultsexercises the databaseLogin succeedsexercises auth and sessionCheckout reaches paymentand stops thereFour checks, three regionstwelve runs a minuteEach journey exercises a different subsystem. That is how four is enough.
Fig 1. The four journeys and why each one earns its place. Together they cover the web tier, the database, authentication and the payment integration.
  • Machine learning
  • Security & identity
  • Analytics
  • Front-end & mobile

The value is in the coverage rather than the count. Home loading proves the web tier and the CDN. Search proves the database is answering. Login proves authentication and sessions. Checkout proves the payment integration is reachable. A failure in any one of them points at a different part of the system, which is most of the diagnostic value.

Rules that stop a check causing damage

What a check must never do

  • Never complete a purchase. It stops at the payment step. A check that completes an order every minute creates 1,440 orders a day and a genuinely awkward conversation with accounts.
  • Never send a message. No password resets, no contact form submissions, no SMS. Every one of those reaches a real system with a real cost.
  • Never write customer data. The check account’s basket is emptied at the start of each run rather than the end, so a failed run does not leave state behind.
  • Never be counted. The check account is flagged, its user agent is identifiable, and analytics, revenue reporting and recommendation systems all exclude it.
  • Never hold a lock. If the checkout reserves stock, the check uses an item with a stock level that is deliberately enormous.

The analytics exclusion is the one most often forgotten and it distorts more than people expect. Twelve runs a minute is seventeen thousand sessions a day, and a small business’s traffic figures, conversion rate and most-viewed-product report are all meaningfully wrong if those are included.

Slow is not down

How response time maps to status statesA horizontal row of five boxes. Eight hundred milliseconds: normal. Three seconds: slow, and recorded. Eight seconds: the step timeout, so the check has failed. Degraded: a separate state. Down: only when a check actually fails. A note says a status page with only up and down cannot describe the most common bad afternoon.SLOW AND DOWN ARE DIFFERENT STATES800msnormal3sslow, recorded8sstep timeout: failedDegradeda separate stateDownonly when it failsA status page with only up and down cannot describe the most common bad afternoon.
Fig 2. Why timing produces its own state. Most bad afternoons are not outages, and a page that can only say up or down has to lie about them in one direction.
  • App integration
  • Security & identity
  • Management
  • Analytics

A journey that succeeds in three seconds when it usually takes eight hundred milliseconds is not down and is not fine. That state is degraded, it appears on the status page in its own colour, and it is reported separately — because “the site is slow” is the most common customer complaint and a status page that says everything is operational during it is actively unhelpful.

Next: how three regional opinions become one decision.

All posts