Separate build and runtime logs

Build logs exist while Vercel installs and compiles the application. Runtime logs exist when deployed code handles requests and emits output.

Start with the phase that failed. A missing dependency or type error belongs to the build. A database timeout after a successful build belongs to runtime. Filter by project, environment, deployment, time, route, and severity where available. Preserve request or trace identifiers so one user report can be followed across services.

Build logs explain one immutable artifact: installation, framework detection, compilation, and output generation. Runtime logs explain invocations after that artifact receives traffic. Activity or audit history explains configuration and deployment changes. Choosing the wrong stream wastes time and can make a rebuild look like a fix.

Include deployment ID, route template, status, duration, request ID, and a safe error class in structured runtime logs. Never log full headers, bodies, cookies, or environment objects. Retention and available filters depend on the current plan, so route important alerts and evidence to a durable system rather than assuming the dashboard is permanent storage.

Create one Preview build failure and one guarded runtime failure. Find each in the correct log view and write the smallest factual diagnosis.