A deployment from GitHub to AWS can leave logs in several places. Take a Node API that CodeBuild packages into an image, ECR stores, and App Runner runs. When the team pushes a new commit and the build succeeds but the App Runner update fails, the engineer needs to find out whether the new app process ever started.
Trace the commit to its build, the image that build produced, and the App Runner operation that tried to use it. Once you know how far the release got, you can open the CloudWatch logs for the relevant stage. Adapt the same sequence to the services in your own pipeline.
Make the release easy to follow
The example API, Parcel, has staging and production services with similar names. Start by recording the AWS account and Region to confirm which service you're investigating. Then collect the identifiers that link each stage so someone else can follow the same release without relying on timestamps alone.
| Stage | Evidence to save | What it can establish |
|---|---|---|
| Source | Commit and pipeline run | Which code entered the workflow |
| Build | CodeBuild build ID, phase, and logs | Whether the build steps finished |
| Image | ECR repository and image digest | Which image the build produced |
| Deployment | App Runner service and operation | Which update AWS tried to run |
| Running app | App logs and request identifiers | What happened after the process started |
Save the image digest, which identifies the exact image the build produced. A tag such as latest can point to another image after the next build, so testing that tag later may give the engineer a different image from the one that failed.
Save the identifiers as the workflow runs where possible. Rebuilding them from several consoles during an outage takes longer and leaves more room for a bad match.
Read CodeBuild when the build failed
Open CodeBuild's Build history and select the build ID from the release record. Check the failed phase and the command output. CodeBuild also exposes build details through batch-get-builds if that fits your workflow. AWS CodeBuild build details
Suppose Parcel fails while installing packages. The final line may say only that a command exited with an error. Read upward to the first useful package error. Then compare the package command, lockfile, and tool version with the source commit used by this build.
In a monorepo, verify the build directory as well as the commit. A build can use the intended commit and still package a different app if it starts in the wrong directory.
Once the build has produced the expected image, move on to the deployment evidence. A successful package install cannot show whether the container has the right database settings when it starts.
Check which image App Runner tried to use
Follow the build output into ECR and compare the image with the App Runner operation. Confirm the repository, image identity, and update time. A successful build sitting in ECR does not establish that App Runner selected it.
For Parcel, the comparison might show that the pipeline built the new commit without triggering an update for the intended service. It might also show that the successful operation was for staging while the production update failed. Either finding helps the engineer select the right operation before changing app code.
Use the exact release identifiers to resolve that question before opening a broad log search. You want the logs from the operation that tried to run this image.
Use App Runner's service and application logs together
App Runner sends service logs and application logs to separate CloudWatch Logs groups. Service logs describe lifecycle and deployment work. Application logs contain output from running app instances. Their names are under /aws/apprunner/, include the service name and ID, and end in /service or /application. App Runner CloudWatch Logs guide
Use the failed operation and its time to find the corresponding deployment logs. If they show that the process started, check application output from that part of the rollout.
For Parcel, a failure to access the image belongs to the deployment path. An exception after the app reads DATABASE_URL belongs in startup output. Those errors may both produce a failed deployment status, but their next checks differ.
If there is no app output, use the deployment logs to check whether App Runner started the process. Even if it did, the app may have exited before writing its first log line.
Leave useful evidence inside the app
Have Parcel print a safe release identifier at startup. Include request IDs in application logs so a failed customer action can be traced after the deployment succeeds. Under concurrent traffic, timestamps alone may mix unrelated requests.
Start with the relevant service, release time, and error so the search returns fewer unrelated lines. Expand the time range if you need to follow the error into an earlier or later stage.
Avoid logging full connection strings, access tokens, or customer records. A useful message might say which required setting is missing without printing other settings. Review output before sharing it outside the people who need it.
Rehearse the map with two safe failures
Use a disposable Parcel service with synthetic data. First, make a build command fail in a test commit. Follow that commit to its failed CodeBuild phase and save the route to the error.
Then restore the command and make the app exit at startup with a clear test message. Follow the new build and image to the failed App Runner operation, and check whether you can find that message in the application output.
Ask another engineer to find each error using the saved map. If they need you to explain which run to choose, add the missing identifier or link. Give them only the access needed for that work; the map should not depend on an account admin credential.
Follow a Forte Service through the same stages
Forte connects a Service to a GitHub repository and branch. Its deployment detail page records build and deploy steps, including health check discovery. GitHub deployment status links back to that page on a best-effort basis. Start there when a new revision fails. Forte deployment guide
Once the Service receives requests, use Requests and the application logs to inspect failures. Forte supplies an X-Request-Id header. Include it in the app's log lines to match concurrent requests more accurately. Websites bypass this Service request log path. Forte monitoring guide
Build and deployment logs are included with Forte builds; build runs are billed by tier. Your app still needs to emit safe, useful messages. Forte build pricing
Run the same two drills on a test Service and save the commit and deployment link for each. Ask another engineer to start with those links and see whether they can find the first useful error.