Suppose you run an order API on AWS App Runner. It stores orders in Postgres and can send confirmation emails later, so customers can check out while the email provider is down. After a database problem stops the API from saving orders while /health still returns 200, you add a check for every dependency. When the email provider slows down, App Runner marks instances unhealthy even though they can still save orders.
Decide what you want the host to do when a health check fails, then test the conditions that make that response helpful. Give the full order flow its own test so you can catch a customer-facing failure even when every API instance looks healthy.
Start with the action a failed check will cause
For an order API like Parcel, a liveness check asks whether the process responds or might need to be replaced. A readiness check asks whether the instance is ready to receive traffic. A synthetic check runs a task from outside the app, such as placing a test order, to see whether the user flow works.
Check which controls your host provides. App Runner has one configured service health check mechanism, using TCP by default or HTTP when selected. With HTTP, you choose a path and timing settings. Do not assume it offers separate Kubernetes-style liveness and readiness routes. App Runner health check settings
Parcel's team makes /health respond through the app server once required setup has finished. The team exercises order storage and email delivery separately so it can see which part of the user flow failed.
Choose dependencies by what failure means
Before adding a dependency to /health, ask what would happen if it failed. Would taking this instance out of service help a customer request succeed somewhere else?
If one Parcel instance has the wrong database setting, a healthy peer may still serve orders. If the shared email provider is down, marking every API instance unhealthy could interrupt checkout even though those instances can still save orders.
| State | Possible design choice | Why the choice may help |
|---|---|---|
| One instance has invalid required config | Fail its health route or exit at startup | It cannot do its intended work |
| Required app routes have not loaded | Keep the health route unsuccessful | The process is not ready to serve |
| Shared email provider is unavailable | Keep core order health successful | Orders can still be saved |
| Optional report service is slow | Show the fault in protected diagnostics | Core order routes may still work |
An app that depends on its database for every request may need a database check with a timeout. An app that can still serve useful cached data may want its instances to keep taking traffic. Write down what the app can still do when a dependency fails so reviewers can see why the check works that way.
The check's name should match its promise. If /health only proves that the server responds, someone should not read its green status as proof that payment, email, and storage all work.
Keep each probe cheap and bounded
Platforms call health routes often, so a query that seems harmless on its own can add load when probes run across many instances. Avoid scanning tables or opening a fresh database connection each time the host checks the route.
If the check performs I/O, give that work a tight timeout. A stuck dependency should not leave health requests piling up forever. Choose the timeout in relation to the platform's own check settings so the app can return a useful result in time.
Keep the response small and free of private details. A public route can return a simple status. Database addresses, stack traces, and provider errors belong in protected diagnostics or safe logs.
Also confirm that the route runs through the server you intend to check. A static page served by a separate layer might keep returning 200 while the API router is broken. Parcel needs evidence that its API process answers the check.
Test the green state and the failure states
Start with a normal test deployment and record the status and duration of a request to /health. Then save a synthetic order through the API. The first result shows that the process answers the probe, and the second shows that the order path can save a record.
Next, remove a required setting in staging. The process should exit with a useful message or keep its health route unsuccessful, according to the design. A green route in this state would hide a fault the team meant to catch.
Delay the optional email provider. Check that Parcel still saves an order if that is its promised behavior. Its diagnostics should show the email problem without claiming that the entire API is unusable.
Where your test setup supports multiple instances, make one unhealthy while another remains healthy. Record where the host sends traffic, whether it replaces the unhealthy instance, and how long those actions take in your setup.
Give the full user flow its own test
Parcel's /health cannot prove that a customer can sign in and save an order. Schedule a separate test with synthetic data that does that work. Use the appropriate payment test setup if checkout is part of the path.
Keep test records easy to recognize and safe to remove. Ensure the test cannot email real customers or collect a live payment. Check the final saved state, rather than treating a successful browser page as proof that the order reached the database.
Assign someone to respond when the order test fails. If the health route is still green, the responder can use the test's failure to investigate an app bug or a shared provider outage.
Make the route clear on Forte
Forte Services need an HTTP GET route that returns a success status for deployment checks. Forte inspects the app to discover the port and health path, so make the route clear in the code and check the detected values on the deployment. If you change the port or path, review the saved configuration and reset discovery when needed. Forte deployment guide
A probe sent to the public Service address also passes through gateway authentication. If it needs public access to /health, add a narrow auth exclusion and test it. Internal deployment checks and public probes take different paths, so check both. Leave sensitive details out of the public response. Forte Service auth exclusions
Forte includes health checks and rollback for failed Service updates when a previous healthy revision exists. That rollback does not prove that a new database change is safe. Your team still checks the order flow and the data it saves. Forte build features
For Parcel, the next useful step is to write one sentence describing what /health promises. Use the deployment guide to connect that route, then test the specific failure it is meant to catch.