Troubleshooting
Diagnose common problems with connections, execution, realtime updates, email, and self-hosted services.
First work out which layer the problem lives in: the Multica service, the daemon, the runtime, or the AI coding tool. These commands are usually enough to surface the first meaningful error:
multica version
multica auth status
multica daemon status --output json
multica daemon logs --lines 100/health only says the API process is responding; /readyz also checks the database and migrations. Include the error, relevant logs, CLI version, and operating system when reporting a problem; remove tokens, email addresses, and other sensitive details before submitting.
Connection and sign-in
Runs and AI coding tools
Web app and self-hosted service
Log locations
| Component | How to view |
|---|---|
| Background daemon | multica daemon logs --lines 100 |
| Follow daemon logs live | multica daemon logs --follow |
| Default profile's log file | ~/.multica/daemon.log |
| Default profile's startup or crash log | ~/.multica/daemon.err.log |
| Named profiles | the matching logs under ~/.multica/profiles/<name>/ |
| Docker backend | docker compose -f docker-compose.selfhost.yml logs -f backend |
| Browser | Console and Network in the developer tools |
Which of those files is the live one depends on the profile the daemon was started with, and a stale log from an earlier daemon still reads perfectly — the easiest way to debug the wrong file. Don't open one by guess: multica daemon logs prints the absolute path it resolved before streaming it. Add --profile <name> to read a named profile's log.
To observe the daemon's startup directly, run it in the foreground instead:
multica daemon stop
multica daemon start --foregroundIf you still cannot pin it down, search existing issues or file a new one on GitHub Issues.
Next steps
- Daemon and runtimes — how runtimes register and report online status.
- Runs — status, timeout, and failure reference.
- Environment variables — the full self-hosting configuration reference.