News and analysis
Customer-journey checks: ownership before and after release
Grafana adds folders for synthetic checks; Postman describes CI load tests. Separate environments, criteria and responsibility for the result.
The team sees dozens of green checks but cannot quickly establish whether a customer can move from sign-in to order submission. Some checks target staging, others production, and ownership is implicit. Two October publications help organize that collection around the product journey.
Recurring checks need an owner
On 7 October, Grafana announced general availability of Synthetic Monitoring folders. They group checks by team, service and environment, with folder permissions and bulk actions. This organizes checks; it does not itself establish product availability.
Start with one customer journey, such as signing in, viewing an order and opening a document. Identify the automatically checked step, notification recipient and expected response. If persistence is outside the test, a green read check does not establish that a new request can be submitted.
Distinguish staging and production explicitly. Similar names should not conceal different data sources. During maintenance, identify which checks are disabled and who will restore them afterwards.
A release condition examines another workload
The 9 October Postman article describes cloud load runs and passing conditions in CI. That supports a release decision rather than replacing recurring availability monitoring.
The comparison suggests that one journey can need different checks at different stages. Before release, verify behaviour under an agreed load; afterwards, inspect whether the live path remains usable. A journey owner can connect the results without confusing what they mean.
Give the responsible person usable context
For each check, keep a short record of the journey, environment, expected result, sample-data source and response route. A threshold should reflect the requirements of the specific action rather than a number copied from a vendor example.
In a separate environment, trigger a controlled failure of one step. Establish that the check reports the relevant journey and supplies enough context for the owner to begin investigation. Then test recovery and the update needed after an interface change.
Check configuration access too: an accidental edit to one team’s test should not alter another team’s checks. Keep release criteria separate from daily notifications. This supports discussion of an actual result rather than a reliability promise based on the number of green indicators.
The checks should remain understandable when ownership changes. A new maintainer needs the scenario and its purpose, not merely a schedule and an alert address.
Our first customer-portal release guide helps select the complete journey. The rental application project provides product context without claiming these monitoring tools were used. For your customer product, discuss scenarios, environments and owners.