Optional structured diagnostics when a container fails to start

[Gautam-aman]

I've been looking at how Testcontainers handles startup failures and wanted to suggest a small developer-experience improvement.

When a container fails to start in CI, the exception and container logs are useful, but diagnosing the failure can still require digging through the CI output and checking different Docker-related details.

Would it make sense to provide an opt-in structured diagnostics artifact when startup fails?

I was thinking of something containing the image name, container ID where available, startup duration, failure stage, exit code, wait-strategy information, and a bounded tail of container logs.

This could be attached to CI test reports, making failures easier to compare and investigate.

I noticed #11998 already improves startup error handling. This proposal is slightly different: it would provide a structured diagnostic artifact rather than only improving the exception or logs.

I'd start with a minimal JSON representation and tests covering startup failures, missing logs, and sensitive-information handling. No automatic environment-variable dumps or unrestricted log collection.

Does this sound like something the project would want? If there's interest, I'd be happy to open a focused feature issue and work on the implementation.