Check backup job status

Give the SuperIT agent a way to answer "did last night's backup work?" by reading recent job results from your backup platform's API. For MSPs and IT teams whose backup console has a REST API.

Why use an action instead of asking SuperIT

SuperIT has no access to your backup platform. It can't store its API key and can't call arbitrary web APIs, only search the public web. This action holds the credential encrypted, calls the backup platform's API in the cloud sandbox, and answers "did last night's backup work?" from the backup console itself. Pair it with a schedule and a Teams or Slack post for a daily failed-backup alert.

For what the device itself shows, such as whether the backup agent's service is running or its disk is full, just ask SuperIT in chat.

When to use it

• "Did SRV-FS01 back up last night?"
• "Which backups failed in the last 24 hours?"
• "The customer says they can't restore a file. When was the last good backup?"
• Every morning, tell the team which backups failed overnight.

The SuperIT agent runs the action and answers from the job results.

What the action does

1. Reads the optional device and hours inputs. hours defaults to 24.
2. Calls the backup platform's jobs endpoint with the API key from the linked credential.
3. Keeps jobs that finished within the window, filtered to one device if you gave one. The device filter matches any device name that contains the text, so SRV-FS matches SRV-FS01 and SRV-FS02.
4. Prints failed and warning jobs first, then a count of successful ones, and returns the same data as a result.

What it doesn't do:

• It doesn't start, retry or cancel backups. That is a write; give it its own action and approval.
• It doesn't check that a backup can be restored. A successful job isn't proof of a working restore.
• It doesn't reach a backup server on a private network. For an on-premises console, run a PowerShell action on a device that can reach it. See Query an on-premises system from a device.

Before you begin

• A credential. Under Workflows → Credentials, select New, name it Backup API and choose the Auth scheme your backup vendor uses. This guide assumes Other (Bearer token), which the script reads as CREDENTIAL_BACKUP_API_AUTHORIZATION. Check the credential's Script environment variables panel for the exact name. See Credentials.
• A read-only API key or reporting role in the backup platform.
• The backup API's base URL and jobs endpoint from your vendor's API documentation.
• No authorization policy is needed for a read-only check. See Approvals.
• Your role. Creating an action in chat needs the Admin role. Engineers can build it by hand under Workflows → Actions.

Build it with SuperIT

Create an action called "Check backup job status".
Purpose: list backup jobs from our backup platform in the last N hours, failures first, optionally for one device.
Runtime: PowerShell in the cloud sandbox, using Invoke-RestMethod.
Inputs: device (string, optional), hours (string, optional, default 24).
Credential: our "Backup API" credential (Bearer token). API docs: <link to your backup vendor's API docs>.
Read-only. Print failed and warning jobs with device, job name, finish time and error message, then a count of successful jobs.
No authorization policy: engineers and admins only, no approval.

SuperIT drafts the script against the endpoint in your vendor's API documentation, validates it and creates the action as a draft. You review it, test it and publish it under Workflows → Actions.

Or build it yourself

Set Runtime to PowerShell, then adapt the URL and field names to your vendor:

# Goal: list backup jobs that finished in the last N hours (optionally for one device), failures first. Read-only.
$baseUrl = "https://api.backup-vendor.example/v1"   # your backup platform's API
$auth = $env:CREDENTIAL_BACKUP_API_AUTHORIZATION

function Invoke-BackupJobCheck {
    param([string]$Device, [string]$Hours)

    $deviceFilter = $Device.Trim().ToLower()
    $window = ConvertTo-HoursWindow -Hours $Hours
    Assert-Credential
    $jobs = @(Get-BackupJob -SinceHours $window -Device $deviceFilter)
    $problems = @(Select-ProblemJob -Jobs $jobs)
    # Cap the list so the output stays readable and under the output limit.
    $shown = @($problems | Select-Object -First 25)
    Write-BackupReport -Device $deviceFilter -Hours $window -Jobs $jobs -ProblemCount $problems.Count -Shown $shown
    # $script: so the runner can still read $result after this function returns.
    $script:result = @{
        hours      = $window
        device     = $deviceFilter
        total      = $jobs.Count
        successful = $jobs.Count - $problems.Count
        problems   = $shown
    }
}

function ConvertTo-HoursWindow {
    param([string]$Hours)
    if ([string]::IsNullOrWhiteSpace($Hours)) { return 24 }
    $value = 0
    if (-not [int]::TryParse($Hours.Trim(), [ref]$value)) { throw "Input 'hours' must be a whole number." }
    if ($value -lt 1 -or $value -gt 168) { throw "Input 'hours' must be between 1 and 168." }
    return $value
}

function Assert-Credential {
    if (-not $auth) { throw "The 'Backup API' credential is not linked to this action." }
}

function Get-BackupJob {
    param([int]$SinceHours, [string]$Device)
    $since = [datetime]::UtcNow.AddHours(-$SinceHours).ToString('yyyy-MM-ddTHH:mm:ssZ')
    $uri = "$baseUrl/jobs?since=$([uri]::EscapeDataString($since))"
    try {
        $response = Invoke-RestMethod -Uri $uri -Headers @{ Authorization = $auth; Accept = "application/json" } -TimeoutSec 60
    } catch {
        throw "Failed to list backup jobs for the last $SinceHours hours: $($_.Exception.Message)"
    }
    $jobs = @($response.jobs | Where-Object { $_ })
    if ($Device) {
        $jobs = @($jobs | Where-Object { "$($_.device_name)".ToLower().Contains($Device) })
    }
    return $jobs
}

function Select-ProblemJob {
    param([object[]]$Jobs)
    return @($Jobs | Where-Object { "$($_.status)".ToLower() -notin @('success', 'succeeded') })
}

function Format-When {
    param($Value)
    # Invoke-RestMethod turns ISO timestamps into [datetime] objects.
    if ($Value -is [datetime]) { return $Value.ToUniversalTime().ToString('yyyy-MM-dd HH:mm') + ' UTC' }
    return "$Value"
}

function Write-BackupReport {
    param([string]$Device, [int]$Hours, [object[]]$Jobs, [int]$ProblemCount, [object[]]$Shown)
    $scope = if ($Device) { "device '$Device'" } else { "all devices" }
    Write-Output "=== BACKUP JOBS ==="
    Write-Output "Scope      : $scope"
    Write-Output "Window     : last $Hours hours"
    Write-Output "Total      : $($Jobs.Count)"
    Write-Output "Problems   : $ProblemCount failed or warning"
    Write-Output "Successful : $($Jobs.Count - $ProblemCount)"
    foreach ($j in $Shown) {
        $message = "$($j.message)"
        if ($message.Length -gt 200) { $message = $message.Substring(0, 200) }
        Write-Output "- $($j.device_name) | $($j.job_name) | $($j.status) | finished $(Format-When $j.finished_at) | $message"
    }
    if ($Jobs.Count -eq 0) {
        Write-Output "No jobs found in this window. Check the device name, or whether backups are scheduled."
    }
}

Invoke-BackupJobCheck -Device $ctx.inputs.device -Hours $ctx.inputs.hours

The script caps the list at 25 problems so the output stays readable for SuperIT and under the 256 KB output limit.

Test it

1. Save the draft and select Test.
2. Test is not a dry run: it skips authorization and approvals and uses the real credential and network access. This action only reads, so testing is safe. Test runs aren't billed.
3. Run it once with no inputs, then with a device you know has a recent failure or warning.
4. Compare the output with the backup console. Check that the time window and the status values match how your vendor reports them.
5. Select Publish.

Use it

• In chat: "Which backups failed overnight?" or "When was SRV-FS01's last good backup?"
• On a schedule: ask SuperIT "Run Check backup job status every day, starting tomorrow at 07:00, with hours 24". Schedules are created in chat only and repeat every N elapsed days (24-hour days, not calendar or cron schedules). SuperIT shows a View schedule link. A scheduled run's output isn't sent anywhere: it stays under the action's Executions tab. For an alert, add the webhook call from Post a message to a Teams or Slack channel to this script and post when a job failed. Actions can't call each other, so the call must be in this script, with the webhook credential linked to this action.
• Managed teams: if each customer has its own backup account, use Publish to teams. Each managed team gets a read-only copy and a blank Backup API credential for its admin to fill in.

Variations

• Missing coverage: compare the backup platform's protected devices with the devices SuperIT manages and list devices with no backup job.
• Storage and retention: read the account's storage use and retention settings and flag anything near its quota.
• Portal without an API: use a Playwright action to sign in and read the job list. See Download a report from a vendor portal.

Related

• Call a third-party API
• Send a weekly summary report
• Credentials
• Approvals