What causes "Managed restart did not produce healthy runtime services." in paperclipai/paperclip?

Inspect the workspace operation and the services' own logs (startRuntimeServicesForWorkspaceControl captures output) for the crash or unhealthy reason.

paperclipai/paperclip · error

Managed restart did not produce healthy runtime services.

Error message

Managed restart did not produce healthy runtime services.

What it means

Thrown in the readiness_validation phase of repair after a managed restart of runtime services. When repair was asked to restart services, every started service must end up status "running" AND healthStatus "healthy"; an empty start list or any service that is not running/healthy fails the phase (server/src/routes/execution-workspaces.ts:848). The repair operation is marked failed at this phase even though the database reseed itself succeeded.

Source

Thrown at server/src/routes/execution-workspaces.ts:848

                    ?? null,
                },
                adapterEnv: {},
                onLog,
                recorder,
              });
            }
            runtimeServiceCount = startedServices.length;
            await reportRepairPhase("managed_restart", "succeeded");

            await reportRepairPhase("readiness_validation", "started");
            if (
              repairRestartsRuntimeServices
              && (
                startedServices.length === 0
                || startedServices.some((service) => service.status !== "running" || service.healthStatus !== "healthy")
              )
            ) {
              throw new Error("Managed restart did not produce healthy runtime services.");
            }
            await reportRepairPhase("readiness_validation", "succeeded");
          } catch (error) {
            await reportRepairPhase(repairPhase, "failed");
            throw error;
          }
        } else if (action === "stop" || action === "restart") {
          await stopRuntimeServicesForExecutionWorkspace({
            db,
            executionWorkspaceId: existing.id,
            workspaceCwd,
            runtimeServiceId: selectedRuntimeServiceId,
          });
        }

        if (action === "start" || action === "restart") {
          const availableWorkspace = await ensureWorkspaceAvailable();
          if (!availableWorkspace) {

View on GitHub (pinned to a7e689b3c3)

Solutions

Inspect the workspace operation and the services' own logs (startRuntimeServicesForWorkspaceControl captures output) for the crash or unhealthy reason.
Check for orphaned listeners on the service ports and terminate them, then run the restart action.
Fix the root cause in the worktree (apply migrations, restore required env/secret files) — the DB repair already succeeded, so a plain start/restart is enough afterwards.
If health checks are just slow, retry restart once the service finishes warming up.

Defensive patterns

Strategy: retry

Validate before calling

const services = listConfiguredRuntimeServiceEntries({ workspaceRuntime: effectiveRuntimeConfig });
if (services.length === 0) { /* repair skips restart + readiness check entirely */ }
for (const s of await api.getRuntimeServices(id)) { if (s.status !== "running" || s.healthStatus !== "healthy") throw new Error(`Service ${s.id} not healthy; check its logs before repair.`); }

Try / catch

try { await repair(id); } catch (err) { if (/healthy runtime services/.test(String(err?.body?.error ?? ""))) { await inspectServiceLogs(id); await restartServices(id); /* DB repair already succeeded */ } else throw err; }

Prevention

Make sure worktree services can boot against a freshly seeded database (migrations, env vars, secrets).
Free the service ports of orphaned processes before repair.
Give services a realistic health-check window so slow starts do not fail readiness.

When it happens

Trigger: POST repair on a workspace with configured runtime services where startRuntimeServicesForWorkspaceControl returns zero services or at least one service whose status !== "running" or healthStatus !== "healthy" — app crashes on boot against the freshly seeded DB, health endpoint never turns healthy, port conflict from a service that survived the managed stop.

Common situations: The reseeded database has schema/data the service build does not expect (version skew between worktree code and seed); service startup slower than the health window; a stale process still holding the service port after managed_stop; missing env vars or secrets the service needs inside the worktree; migrations not applied by the service on boot.

Related errors

AI-assisted analysis of paperclipai/paperclip@a7e689b3c3 (2026-08-21). Data as JSON: /api/errors/1b9b241cc28ebce6. Report an issue: GitHub.