Your team runs a TypeScript order API in a container and saves orders in Postgres. When you release a new version, the build succeeds and the server starts. The first attempt to save an order fails because the app cannot reach Postgres, so the place to look is the log for that request.
Start with the logs from the point where work stopped. Use the build log to see how the team packaged the code, the startup log to see how the server launched, and the runtime log to see what the app did with a request. Keep track of the commit and image so you can follow the same release across all three logs.
Follow one app through the three phases
Parcel's release pipeline compiles the TypeScript code, packages it in a container, and deploys the image. Here is where you would look if this example API failed at each stage.
If tsc reports a type error, start with the failed build command and the first compiler message that names the problem. The pipeline may have stopped before it produced a new image.
If the image exists but Parcel exits because DATABASE_URL is missing, check the new process's output, its start command, and the configuration the deployed app receives. The database setting in this example is read at startup, after the compiler has finished.
If Parcel starts and passes its health check before timing out on an order lookup, use the request record and application logs to find the database operation that stalled. That work took place at runtime, after the build and startup checks had passed.
Ask how far the release got
A failed health check can mean the app quit, started but could not be reached, or gave the wrong response. Read the startup log to see whether the app got far enough to answer the check.
Use the symptom to pick a starting point, then use the logs to confirm which phase failed.
| What you see | Start here | What to check next |
|---|---|---|
| No new image was produced | Failed build command | Tool version, lockfile, source directory |
| Image exists and process exits | Startup output and exit details | Start command, imports, required settings |
| Process stays up but health check fails | Server startup and health route | Address, port, path, response time |
| Only some requests fail | Request record and related app logs | Input, dependency, running release |
| Requests slow as instances increase | Pool waits and database metrics | Combined pools and database capacity |
For Parcel, confirm that the order request reached the new release. A browser might still be calling the old address, or traffic may be split during a rollout. Include a safe release ID in startup logs so you can compare what is running with what you intended to deploy.
Check when the app reads a setting
A missing environment variable can cause either a build error or a startup error. Some frameworks read settings while compiling pages or generating assets. Others wait until the server process starts.
Find the command that tried to use the missing value. A build-time setting needs to be available to the build, while a startup secret needs to reach the deployed process. Check the environment for the command that failed rather than assuming it sees the same values as your local shell.
Record the name of the setting, where you supply it, and whether the process can see it. Check that setting on its own, since printing the whole environment can expose database passwords and provider keys.
The same rule helps with other languages. A Python import failure may occur only in the final image because the local checkout has extra packages installed. A JVM startup exception may wrap the useful cause several levels down. Save the full exception chain, then identify the missing dependency or invalid setting it names.
Reproduce the failure with the deployed image
To check why Parcel quit, run the same image with its usual start command in a test setup. The app may start from a local checkout even when a file or package is missing from the image.
For a request failure, use a synthetic input that reaches the same route and dependency. Record the request ID, time, status, and release, then keep the input fixed while testing a new image so you can see whether the image change fixed the fault.
On AWS, CodeBuild provides the build run and phase details. App Runner separates deployment work from application output, so a passing build followed by a failed rollout often needs both sources. CodeBuild build details, App Runner logs
Add the log line you wished you had
Once you know why Parcel failed, add the details you needed to find it. Log the release ID at startup and name any required setting that is missing. While handling a request, include its ID when you log an error or call another service.
Log the operation that failed and how long it waited. “Order lookup timed out after the configured database wait” gives the next engineer a more useful place to start than “something went wrong.” Keep personal values and credentials out of that message.
Test the behavior and the logs together in staging. When you force a query to fail, check that the app returns the connection to the pool and records the failed operation. When you omit a required setting, check that the startup message names the setting without exposing any secret values.
Use Forte's deployment view before its request view
If a Forte Service fails during a release, open the deployment detail page to see its build, health discovery, and deploy steps. If you changed the app's layout, runtime, port, or start path, check what Forte detected against the new code. Reset detection if the saved settings no longer fit. Forte deployment workflow
Once requests reach the Service, inspect a failed request and its application logs. Include the supplied X-Request-Id in log lines. Timestamp matching is the default and can be less precise when several requests run at once. Websites bypass the gateway and do not have this Service request view. Forte request correlation
Forte includes build logs with billed build runs and documents 90-day retention for app logs and request records. Your team chooses what the app logs and how it protects sensitive fields. Forte pricing and quotas
On a test Service, reproduce a missing package, a missing startup setting, and a failed order request. Save the log that explains each fault so the next Parcel engineer can start with the symptom and find the corresponding phase.