Read the actual log

The deploy log contains the real error. Scroll to the first error, not the last — everything after it is usually consequence. The last line is typically just "build failed", which tells you nothing.

The usual causes

Different Node/PHP/Python version. Your machine has one; the host defaults to another. Pin it — engines in package.json, a .nvmrc, or the host's runtime setting.

A dependency that's installed locally but not declared. It's in your node_modules from some earlier experiment and never made it into package.json. Locally it resolves; on a clean install it doesn't.

Dev dependencies not installed. Production installs often skip them. If your build needs a tool, it belongs in the dependencies that get installed.

Case sensitivity in imports. import Button from './button' where the file is Button.tsx. Works on macOS, fails on Linux.

Out of memory. Large builds exceed the host's limit. The log says "killed" or "heap out of memory".

Missing environment variables at build time. Some frameworks need them during the build, not just at runtime.

Lockfile out of sync with the manifest, so a strict install refuses.

Reproduce it properly

The most reliable move: delete node_modules and your lockfile's cache, then install from scratch exactly as the host does. Most "works locally" build failures disappear the moment you build clean.

build-fail.txt
Build works locally, fails on <host>. Here's the first error in the
deploy log: <paste, with 20 lines of surrounding context>

Local versions: <node/php/python version, package manager version>
Host versions: <what the log says>

Which of these explains it: runtime version, undeclared dependency,
dev dependency skipped, import case, memory, or missing build-time env
vars? Tell me how to confirm and how to pin it so it can't recur.

Commit your lockfile. Most mysterious "it built yesterday" failures are an unpinned dependency picking up a new release during the deploy.