Troubleshooting

Start with the failed object and preserve its evidence. Record the organisation, project, environment, service or component, operation ID, time, status, and first causal error before retrying.

Choose the Right Guide

• Build troubleshooting — source access, commands, artifacts, and pre-deploy work.
• Infrastructure troubleshooting — diffs, AWS permissions, quotas, resources, and deployment logs.
• Runtime and deployment troubleshooting — health, routes, component access, handlers, databases, caches, and uptime.

Investigation Order

1. Confirm the selected organisation, project, and environment.
2. Open the exact package, service deployment, or infrastructure deployment that failed.
3. Read the first causal error and the stage that produced it.
4. Compare with the last successful package, release, or configuration.
5. Check recent changes to source, variables, permissions, connections, domains, and AWS state.
6. Change one understood cause, then create a new attempt.

Use Architect With Context

Deployment, log, metric, and activity views can open Architect with the relevant project context. Ask it to explain the failure and propose a minimal change, then verify the proposal against the source logs and configuration diff before applying it.

Avoid Destructive Diagnostics

Do not delete retained data, widen public access, disable encryption, or grant administrator permissions simply to see whether a failure disappears. Prefer read-only inspection and the smallest reversible change that tests the suspected cause.