Discover & define
Define success criteria
Start with what must still work for a caller or operator after a move. Choose an observable result, then say what a successful result looks like.
Last reviewed 23 October 2026
Search runs in your browser. No account needed.
Begin at the workload boundary
Open Success criteria and choose a workload interface. For a web app behind a load balancer, the useful outcome is the response at the app entry point. An internal container port is a diagnostic detail unless another system depends on that interface.
API or website
Given a safe request, the response returns without an error and includes the expected field.
Processing job
Given a synthetic event, the expected result is produced. Confirm that the selected test runner can observe the result or effect you need.
Infrastructure
A selected target property meets an explicit requirement. For example, available address capacity is at least the agreed minimum.
Build one clear check
- Select the result or interface to observe.
- Choose a condition, such as returning without an error or a field equalling a value.
- Enter the field, threshold or expected value the condition asks for.
- Read the generated “This check will confirm” sentence.
- Give the check a useful name and choose whether it is required.
Required checks determine whether the test passes. Optional checks add information. A package with no required checks does not earn a passing result.
What is a downstream call?
It is a call the application makes to another component or service. Calling DynamoDB can be a valid condition when preserving that interaction is part of the requirement, but “the order was saved correctly” is usually a stronger application outcome than “the SDK was called”.
Choose an in-workload resource when it is the destination. The editor can suggest discovered relationships. Use the explicit external-dependency route when the service is outside the workload. Do not paste an endpoint or invent an internal reference.
Permission to read or write is configuration evidence. Actual calls, returned data and state changes require a runner that can observe them.
Use diagnostics when they help explain failure
Component diagnostics can check a function return value or another internal observation. A downstream call check does not by itself prove correct persistence, retries, ordering or absence of duplicate side effects.
Use Edit check to revise an existing condition. Only one active check of the same observation/condition type is allowed per interface. Saving an edit creates a new version; historical evidence keeps the version it actually tested.
Use safe test data
Review inferred starting values before accepting them. They are structural examples, not recovered production requests. Override them with a static mock when you know the expected behaviour. Mocks cannot establish that the original application code works.