JSON Output Mode

Using the --json Flag

Add --json anywhere on the command line and the commands that support it print one JSON document instead of human-readable text. That makes the output easy to parse in scripts, feed into monitoring tools, or turn into a dashboard. The list of supported commands is below; the others print text whatever flags you pass.

# Human-readable output (default)
backupengine status
# ╔══════════════════════════════════════════╗
# ║       Backup Engine — Agent Status       ║
# ...

# JSON output
backupengine status --json
{
  "status": "protected",
  "email": "admin@example.com",
  "plan": "Professional",
  "device_id": "5b0c2f5e-3c1e-4f0b-9f3a-0d6c2d9a1e77",
  "storage_used": 1288490188,
  "storage_limit": 1099511627776,
  "backup_sets": 3,
  "active_sets": 3,
  "last_backup": "2026-10-27T02:00:04.000",
  "last_status": "completed",
  "recent_success": 5,
  "recent_failed": 0
}

JSON Response Structure

There is no common envelope: each command prints its own object, usually with one top-level key for the list it returns. Times are ISO 8601 strings. Most failures print an error key (a few usage messages are plain text) and exit with code 1.

{
  "sets": [
    {
      "id": "1729600000000",
      "name": "Documents",
      "backup_type": "file",
      "include_paths": ["C:\\Users\\me\\Documents"],
      "exclude_patterns": ["*.tmp"],
      "enabled": 1,
      "schedule_type": "daily",
      "schedule_time": "02:00",
      "last_run": "2026-10-27T02:00:00.000",
      "last_run_status": "completed",
      "file_count": 3847,
      "total_size_bytes": 5368709120,
      "bandwidth_limit_kbps": null
    }
  ]
}

The example is shortened: each set also carries its other stored columns. Booleans such as enabled are 1 or 0, and destinations, additional_schedules and type_metadata are JSON text inside the JSON.

backupengine backup start "Nonexistent" --json
{
  "error": "Backup set \"Nonexistent\" not found"
}
# exit code 1

• •status: one object (see above).
• •backup list [N]: { "jobs": [...] }. Each job has id, backup_set_id, backup_set_name, job_type, status, started_at, completed_at, files_processed, files_total, bytes_processed, bytes_uploaded, chunks_total, chunks_new, chunks_deduped, dedup_savings_percent, progress_percent, error_message and duration_seconds.
• •sets list: { "sets": [...] }, the stored sets as shown above.
• •schedule list: { "schedules": [...] } with id, name, enabled (true or false), schedule_type, schedule_time, the day fields, additional_schedules, the hourly options, summary and last_run. An hourly set also has times_of_day.
• •restore list <set>: { "manifests": [...] } with key, completed_at, started_at, destination, file_count, total_bytes and version_ts (the value --version takes), plus locked_count, parse_error_count, fetch_error_count, unreachable_destinations and latest_load_failures.
• •config get <key>: { "<key>": "<value>" }. The value is always a string.
• •connectivity test: { success, latency_ms, tested_at, error, error_detail } (the last two only on failure).
• •encryption status: configured, unlocked, verifier_version, kdf, active_dek_fingerprint and active_rotation.
• •service-status: { installed, state, label, message }.
• •update check: { current_version, update_available } and, when an update exists, latest_version, install_type, download_url, download_size_bytes and min_supported_violation.
• •gui-status: gui_running, gui_mode, service_running, backup_active, restore_active, running_jobs and more. Its exit code (0, 10, 11, 12) carries the answer for scripts.
• •logs list: { "logs": [...] } with path, size_bytes, modified_at and set_id. logs show prints the log as text.
• •reports list [N], plans list, hyperv list, notifications list, billing status, billing invoices and usage-report show also print JSON, and version prints { "version": "..." }.

Parsing with jq (bash)

jq is the standard tool for parsing JSON in bash scripts. Here are common patterns for extracting data from BackupEngine JSON output.

# Account status
backupengine status --json | jq -r '.status'
# protected

# Last backup recorded by the app or the background service
backupengine status --json | jq -r '.last_backup'

# List all backup set names
backupengine sets list --json | jq -r '.sets[].name'
# Documents
# Source Code
# Photos

# Find sets whose last run failed
backupengine sets list --json | jq -r '.sets[] | select(.last_run_status == "failed") | .name'

# Bytes uploaded by the five most recent jobs, in MB
backupengine backup list 5 --json | jq -r '.jobs[] | "\(.backup_set_name): \(.bytes_uploaded / 1048576 | floor) MB"'

# Restore points of a set: the version_ts value is what restore run --version takes
backupengine restore list "Documents" --json | jq -r '.manifests[] | "\(.version_ts)  \(.completed_at)"'

Parsing with PowerShell

PowerShell natively converts JSON to objects with ConvertFrom-Json, making structured data processing clean.

# Get the account status as an object
$status = backupengine status --json | ConvertFrom-Json
Write-Host "Status: $($status.status)"
Write-Host "Storage used: $([math]::Round($status.storage_used / 1GB, 1)) GB"

# List all backup sets with their last result
$sets = (backupengine sets list --json | ConvertFrom-Json).sets
foreach ($set in $sets) {
    Write-Host "$($set.name): $($set.last_run_status) at $($set.last_run)"
}

# Export the recent jobs to CSV
$jobs = (backupengine backup list 50 --json | ConvertFrom-Json).jobs
$jobs | ForEach-Object {
    [PSCustomObject]@{
        Name       = $_.backup_set_name
        Status     = $_.status
        Started    = $_.started_at
        UploadedMB = [math]::Round($_.bytes_uploaded / 1MB, 1)
    }
} | Export-Csv -Path "backup-report.csv" -NoTypeInformation