Axcient Jobs

SkillAI & models

Axcient x360Recover backup jobs: the BRC vs Replibit job-type split, per-job protection thresholds, and job run history with its starttime_begin pagination floor.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Axcient Jobs skill

What this skill tells your AI

The instructions your AI receives, as published by wyre-ai/msp-claude-plugins in msp-claude-plugins/axcient/axcient/skills/jobs/SKILL.md and read by ahel’s review.

Overview

A job is one configured backup task running against a device — the thing that actually produces recovery points. Jobs always nest under a specific client_id and device_id; there is no organization-wide job list. Get a device's job IDs from axcient_get_device (the jobs array) or axcient_list_devices_by_client first.

Tools

ToolDescriptionArguments
axcient_list_jobs_by_deviceAll jobs for a deviceclient_id, device_id
axcient_get_jobOne job's detailclient_id, device_id, job_id
axcient_get_job_historyRun history for a jobclient_id, device_id, job_id, limit?, offset?, starttime_begin?

There is no job-level list at the organization or client level — jobs are always reached through a specific device.

Job Types: BRC vs Replibit

The job schema is a tagged union — org_level_jobs_response is one of org_level_brc_job or org_level_replibit_job, mirroring the device-level product split (BRC vs X360RECOVER). Handle both shapes: a legacy appliance's jobs return the BRC shape, current-generation appliances and D2C devices return the Replibit shape. Don't assume one field set applies to every job in a fleet with mixed appliance generations.

Job Thresholds

Jobs carry the same threshold structure as devices — vault_rp_threshold, cloud_rp_threshold, local_rp_threshold, protection_threshold — each an object with value, enabled, and overridden. overridden: true means this job's threshold deviates from the client- or organization-level default; check it before assuming a device-level threshold applies uniformly across all its jobs.

Job History

axcient_get_job_history

Parameters:

  • client_id, device_id, job_id -- required
  • limit, offset -- pagination (groups of up to 1500)
  • starttime_begin -- unix timestamp floor; only returns runs starting at or after this time

Known upstream caveat: community testing against Axcient's API found this endpoint unreliable in some environments — treat an empty or unexpected result here as worth double-checking against axcient_get_device_restore_points (which reflects what actually landed, regardless of what the history endpoint reports) before concluding a job has never run.

Common Workflows

Diagnosing a Stale Recovery Point

  1. From axcient_get_device, note which latest_*_rp timestamp is stale and pull the relevant job ID from the device's jobs array
  2. axcient_get_job for the job's current configuration and thresholds
  3. axcient_get_job_history with a starttime_begin a few days back to see whether the job has been running and failing, or not running at all
  4. A job that's running but failing points at a data/connectivity problem on the source system; a job that isn't running at all points at scheduling or agent-health on the appliance/agent side

Auditing Threshold Overrides

  1. axcient_list_jobs_by_device for the device in question
  2. For each job, check thresholds.*.overridden — flag any job whose effective SLA differs from what the client or org default implies
  3. Cross-reference with axcient_get_vault_threshold (see the vaults skill) for the vault-side connectivity threshold, which is separate from a job's own vault_rp_threshold

Error Handling

Job Not Found

Cause: Invalid job_id, or a job_id that belongs to a different client_id/device_id pair than supplied Solution: Re-derive the job ID from axcient_list_jobs_by_device rather than guessing — job IDs are not guaranteed unique outside their parent device.

Job History Returns Empty Unexpectedly

Cause: Either the job genuinely hasn't run in the queried window, or the known history-endpoint unreliability noted above Solution: Widen or drop starttime_begin; corroborate with axcient_get_device_restore_points before reporting "never ran."

Best Practices

  • Always resolve client_id/device_id from a device call first — do not construct job lookups from IDs seen in other contexts.
  • Treat overridden: true thresholds as intentional exceptions worth surfacing explicitly, not noise to filter out.
  • Prefer restore points over job history when the question is "is there a usable recovery point," given the history endpoint's known flakiness.

Related Skills

  • api-patterns - Authentication, tool catalog, error codes
  • devices - Device-level recovery-point timestamps and job list
  • vaults - Vault-side connectivity thresholds

Signals

GitHub stars
45
Forks
24
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
axcient-jobs
Source
github.com/wyre-ai/msp-claude-plugins