Debug a micro that won't start

A micro doesn’t always fail the same way. The key: a micro that doesn’t manage to start (wrong command, missing repo, occupied port) doesn’t write a single line of its own —the reason is in the engine logs—, and that’s exactly the failure that most misleads you if you only look at the micro’s logs.

1. One-shot diagnosis

The fastest: the micro’s diagnosis gathers in a single response its runtime status, what the engine said about it, its errors and its last metrics sample. It doesn’t require the scenario to still be alive: diagnosing after a crash is the normal case.

From the CLI: microlab diagnose <micro>.

2. The logs

In the Logs dock, filter by that micro and by Error level. If you don’t see anything of its own, look at the system sources (engine) — that’s where it appears why it didn’t start.

From the CLI:

microlab logs orders-core -n 500      # its last lines
microlab logs --errors                 # only errors, across the whole scenario
microlab logs -g "connection refused"  # a specific clue

The logs persist: microlab logs works even if the engine is no longer alive.

3. Check the environment

Many startup failures are environment ones (a tool, a credential, Docker missing). The Environment check detects them before launching.

4. Restart just that micro

If you fixed something, you don’t need to relaunch the whole scenario: restart just that micro (in its card/row, or microlab restart <micro>).

See also

• Logs dock · Environment check panel