Issues and health

Issues combine deployment problems, incidents, domain failures, component health, and update advisories. Results are filtered to resources the caller can see.

List issues

const result = await ship.issues.list({ status: "open" });
console.log(result.issues, result.counts);

curl "$OPENSHIP_URL/api/issues?status=open" \
  -H "Authorization: Bearer $OPENSHIP_TOKEN"

status is open or resolved. The result contains issues, counts, and the selected status. Each issue includes its severity, source, target, message, and any supported resolution action. Counts are grouped as outage, actionRequired, advisory, and total.

Clear resolved history

Desktop and self-hosted organization owners/admins can call ship.issues.clearHistory() (or DELETE /api/issues/history). The response is { deleted: number }. This permanently removes resolved incidents in the current organization, including history beyond the feed limit. Active incidents, later recoveries, other organizations, audit logs and notifications remain. The list response exposes canClearHistory for the current caller; read-only and restricted credentials cannot use this operation. The dashboard requires confirmation, and openship monitoring clear-history --yes exposes the same operation from the CLI.

Inspect workload health

const health = await ship.issues.health();
console.log(health.workloads, health.currentScan);

curl "$OPENSHIP_URL/api/issues/health" \
  -H "Authorization: Bearer $OPENSHIP_TOKEN"

The health snapshot includes workload observations, scan timing, and watcher capabilities. It does not start a continuous watcher. scanHealth() requests a fresh one-time check where the host supports it; it refreshes snapshots without opening or resolving incidents. Native scheduling remains disabled unless explicitly configured.

Refresh issue sources

rescan() starts the broader rescan pipeline on self-hosted instances and requires an instance administrator with job-write access. rescanStatus() reads the latest scan's stage statuses, summaries, and failures. A completed stage can still report gaps such as unreachable servers or an offline desktop.

Use rescan({ healthOnly: true }) to run the existing container/server health watcher and reconcile incidents without component updates or domain reconciliation. The REST equivalent accepts {"healthOnly":true} in the body of POST /api/issues/rescan. Omitting the input keeps the full rescan behavior. If a scan is already running, the request returns that existing session; follow its progress with rescanStatus().

A disconnected desktop cannot establish remote server health. The Monitoring page requests a fresh health check on desktop reconnection, and an unreachable-server incident resolves only after the daemon answers successfully.

Operations