A monitoring endpoint, a large expansion of the API, and a fix to how failed database migrations were reported.
Server-side only — the agent is unchanged, so clients stay on 2.77.0 and nothing needs to update.
New: health endpoints for monitoring
Requested so a BBS install can be watched like anything else. Two endpoints, deliberately different:
GET /health → {"status":"ok"} no credentials, 200 or 503
GET /api/v1/health → the full picture (token required)
/health is a liveness probe with no detail — safe to expose and cheap enough for an uptime monitor to poll every few seconds. /api/v1/health reports each subsystem: scheduler freshness, storage fullness per local and remote location, database, catalog engine, client states, failed and stalled jobs, and whether maintenance mode was left switched on.
Each check is ok, warning or critical, the overall status is the worst of them, and the HTTP status follows: 200 for ok and warning, 503 for critical. A monitor that only reads status codes still alerts on the things that stop backups and stays quiet for the things that don't.
The reason this is more than an "is the site up" check: agents keep backing up on their own poll, so a stalled scheduler leaves the web interface perfectly responsive while every server-side job — prunes, compaction, catalog work — silently stops being queued. That is exactly the failure it watches for.
Storage warns at 85% and goes critical at 95%, adjustable per install.
Fixed: a failed migration reported success
A database migration that failed was still recorded as applied. The intent was to stop one bad file blocking every later one, but the effect was that the failure never retried — and because the whole file ran in a single call, the statements before the failure had already applied while the ones after it never did. The result was a partly-migrated schema that looked fully migrated, and the updater printed the error as "Skipped (already applied)" and carried on.
Migrations now run one statement at a time. A statement whose table or column already exists is stepped over and reported as such — the case the original behaviour was protecting, and still the common one on a fresh install. Anything else fails the migration, which is not recorded and runs again on the next update; retrying is safe because the statements that did apply are stepped over on the way back to the one that didn't.
Failures are now loud: the statement, the error and the SQL, and a clear message from the updater rather than a line that scrolls past.
API
A large expansion, mostly around what you can do to a client from outside the web interface. Full reference in the wiki.
Repositories. Only one of the six maintenance actions was reachable before; all are now:
POST /api/v1/clients/{id}/repositories/{repo_id}/maintenance
{"action": "check|compact|repair|break_lock|catalog_rebuild|catalog_rebuild_full"}
compact is the one worth having — it reclaims disk after a prune. Recovery points can also be deleted (DELETE …/archives/{archive_id}, refused while locked), and a catalog rebuild requested directly.
Restore. Search the file catalog across one restore point or all of them, download a selection as a .tar.gz, list a client's database connectors, and restore databases through a single endpoint that picks the right engine from the connector. The file browse now reports whether a catalog is ready, still building, or unavailable — an archive that hasn't been catalogued yet no longer looks like an empty backup.
Client detail. The install command for a client, computed statistics matching the web page, and full write access to plugin configurations — update, delete and test. Plugin secrets are write-only: sent to set them, never returned, and leaving a field blank keeps the stored value instead of clearing it.
Smaller changes. Job listings accept a comma-separated status filter. Archive listings say whether a restore point contains database dumps. Deletion refusals are machine-readable — a repository in use returns the plans blocking it by name, rather than a generic conflict.
Groundwork for future push notifications
Continues the plumbing from 2.77.0. It now has its own Settings section with an explicit Register with Push Notification Service switch: nothing contacts the service until an administrator turns it on, and disabling stops it and forgets the credentials.
Still in development and does nothing yet — enabling it registers the server but delivers no notifications. Safe to leave switched off.