Наразі документація лише англійською мовою. Решта сайту відповідає вашій мові.
Health and updates
Site health checks, release discovery and automatic core updates, admin diagnostics and support bundles, and database migrations.
7 хв читання
Health
Admin → Health. GET /api/health (session) checks database, filesystem (uploads writable), object cache, memory (warn above 90%), and Node version (warn below 22). GET /api/healthz is liveness { ok, installed, boot } without a session. CLI: justflows health.
Updates
Admin → Updates checks the Justflows API (GET /v1/core/latest, backed by the GitHub releases) for the newest stable version. When one is newer than the running version it shows an Update to vX.Y.Z button that downloads the release justflows.zip, verifies it against the published justflows.zip.sha256, and installs it through the same pipeline as a manual upload. A major-version jump is labelled and installs only on explicit confirmation. Administrators can still upload a core zip directly; optional HMAC via JUSTFLOWS_UPDATE_SIGNING_KEY / X-Justflows-Update-Signature and digest pin JUSTFLOWS_UPDATE_DIGEST. The gateway host https://api.justflows.com is fixed in code and cannot be repointed by an environment variable. CLI: justflows update.
Automatic updates — turn this on and a daily job installs newer releases that keep the same major version (0.x → 0.y); it never crosses a major boundary, since that can carry breaking changes. Every attempt, skip, and result is written to the audit log. The server-wide JUSTFLOWS_DISABLE_AUTO_UPDATE variable overrides the toggle.
Updates that finish
The copy / migrate / install / build / restart pipeline used to run synchronously inside the HTTP request that started it, blocking a single-worker host for minutes and occasionally leaving the admin stuck on *“Updating…”* forever. It now runs in a detached worker process: the request returns immediately and both the caller and the admin UI follow progress through GET /api/updates/status (backed by .updates/status.json). A file lock rejects a second concurrent update with 409, a run whose worker died self-heals instead of wedging the UI, the admin page re-attaches to a running update after a reload, and its requests carry timeouts. Dependency install uses pnpm --frozen-lockfile, falling back to npm only when pnpm is missing.
Migrations
POST /api/db/migrate (administrator) or justflows db migrate runs the same SQL the installer uses. After a core zip upload, pending migrations also run when the app boots (and as a step of the updater). Existing sites pick up 0005_content_types this way. Tools exposes migrate alongside WordPress import and the performance suite.
Note
A jobs table and @justflows/jobs scheduler exist; CE does not yet run a full background-job UI. The administrative audit log is implemented — see Security.
Update discovery follows full Semantic Versioning precedence, including prerelease-to-stable updates such as 0.1.7-dev or 0.1.7-rc to 0.1.7.
Diagnostics
Admin → System → Diagnostics is an administrator-only view of runtime, database, migration, cache, plugin, and typed-hook state. Every HTTP response carries a correlation ID, sanitized errors are kept in a bounded buffer, and a persistent warning shows if debug mode is left on in production. A support bundle exports exactly the redacted information previewed on the dashboard — explicitly confirmed and size-limited.
The page also shows plugin scheduler status with safe failed-job retries, and non-destructive database, cache, and scheduler test actions with copyable CLI reproduction guidance (justflows status, justflows health, justflows cache clear, justflows db migrate). Plugins can publish their own permission-gated health checks with ctx.diagnostics.register() after declaring diagnostics:publish — IDs are namespaced by plugin, execution is time-bounded, and returned details are recursively redacted before display or export.