How do you troubleshoot a native image build failure in Quarkus?

Native-image build failures usually trace back to one of a small set of recurring causes, and working through them systematically is faster than guessing.

1. Read the actual GraalVM error output first: messages about "ClassNotFoundException at runtime" or missing resources point directly at a reflection/resource registration gap, not a generic failure.
2. Check for missing reflection registration: a third-party library using reflection without a Quarkus extension covering it often needs a manual reflection-config.json entry or a @RegisterForReflection annotation.
3. Look for unsupported dynamic class loading: code paths that load classes by name at runtime (some serialization libraries do this) frequently need explicit registration or a substitution.
4. Verify extension usage instead of raw dependencies: if a Quarkus extension exists for the library in question, switching to it often resolves native-image issues the extension's authors have already solved.
5. Increase build memory if the failure is an out-of-memory error during the analysis phase, since native-image builds are memory-intensive, especially for large applications.

A useful diagnostic habit is testing incrementally: build natively early and often during development rather than only at the end of a project, so a new failure can usually be traced to whatever dependency or code change was most recently introduced, rather than searching through months of accumulated changes at once.