Skip to content

Case study · Monitoring console · 2026

Unified Backup Monitor

Every client backup checked before the workday starts, and never called healthy without proof.

At a glanceIn production
  • Protected assets watched

    500+
  • Report in Teams, daily

    7:15 AM
  • Console load, was 6–8 s

    ~0.35 s
  • Automated tests

    230+

Built for E3 IT Services' engineers, checking the backups we run for clients

The problem

What it was like before

A backup is only worth something if it ran last night and would restore today. Across many clients that means appliances, agents on individual servers and workstations, cloud continuity, and SaaS backups, spread across more than one vendor, each with its own portal and its own idea of what failed means.

Our previous dashboard only saw part of that picture. Worse, when one of its sources went quiet it could keep showing healthy, because silence looked the same as success.

Checking backups properly meant an engineer opening several portals every morning and working out, client by client, what needed attention. That is exactly the kind of job that gets skipped on a busy day.

Built with

Azure Functions (Node.js)Datto BCDRDatto SaaS ProtectionAxcient x360RecoverAutotask PSALogic AppsMicrosoft TeamsBlob StorageApplication InsightsAzure Static Web Apps

The build

How it works

The short version, before the exploded view goes component by component.

We rebuilt it from scratch as one console over every source: Datto BCDR appliances, Datto endpoint agents including Cloud Continuity, Datto SaaS Protection for every protected domain and app, and Axcient x360Recover.

It checks for every way a backup quietly fails: an appliance offline, local storage at or above 90 percent, an agent or SaaS backup overdue, a recovery point that failed its boot screenshot, an Axcient backup overdue or troubled, a SaaS backup still waiting to finish its first run, and a machine silent long enough that it has probably been retired, which is a billing question rather than a backup failure. Thresholds are set per source in configuration, not buried in code.

The rule that matters most is the simplest one: if a source cannot be read, its backups show as unknown, never as healthy. A quiet vendor API is treated as a problem to look at, not as good news.

Every issue keeps a stable identity, so each morning it is classed as new, ongoing, cleared, or unverified, and every kind of issue carries a recommended first fix. Each day's results are archived, and at 7:15 every morning a report lands in Teams before the first engineer logs in.

Engineers work from a console with health gauges, a queue sorted by severity and grouped by client, a detail drawer with links into each vendor's portal, and a ticket board. They can mark an issue handled with a reason, and open or close its Autotask ticket from the same screen. Automatic filing, one ticket per critical issue with duplicate protection and automatic closing, is built and running as a dry run while it is proven.

The latest state is computed ahead of time, so the console loads in about a third of a second instead of the six to eight it took to ask every vendor live. It runs on Azure Functions with JSON in Blob storage rather than a database server, watched by Application Insights and covered by more than 230 automated tests.

End to end

One failed backup, start to finish

A genuine sequence, which is why these are numbered: from a backup that did not run to the fix that gets it running.

  1. 01

    Collect

    The monitor reads every source on a schedule (appliances, endpoint agents, SaaS protection, and Axcient) and computes the latest state ahead of time, so nobody waits on a vendor.

  2. 02

    Check

    Each asset is tested against thresholds set per source: online, backed up recently enough, verified by a boot screenshot, and below 90 percent storage.

  3. 03

    Refuse to guess

    A source that cannot be read marks its assets unknown, never healthy, and raises an issue of its own.

  4. 04

    Classify

    Every issue keeps a stable identity, so it is classed new, ongoing, cleared, or unverified, with the recommended first fix attached.

  5. 05

    Morning report

    At 7:15 every morning the summary lands in Teams, and the day's results are archived.

  6. 06

    Engineer acts

    The queue is sorted by severity and grouped by client. From the drawer an engineer opens the vendor's portal, then opens an Autotask ticket or marks the issue handled with a reason.

  7. 07

    Cleared

    When the next backup succeeds, the issue clears on its own. Automatic filing and closing of critical tickets runs as a dry run while it is proven.

Architecture

Every moving part

The monitor pulled apart plane by plane, from the backup vendors it reads to the report that lands every morning.

Exploded view

Six planes, 19 components. Select a layer to open it.

  • BCDR appliances

    Datto BCDR

    Appliance check-ins, local storage, and boot-screenshot verification of recovery points.

    Endpoint agents

    Datto agents + Cloud Continuity

    When each protected server and workstation last backed up.

    SaaS protection

    Datto SaaS Protection

    Cloud application backups for each protected domain and app.

    Axcient devices

    Axcient x360Recover

    Overdue and troubled backups on Axcient-protected machines.

Can we build this for you?

This console checks the backups E3 IT Services runs for its clients every morning, and managed backup clients get its attention without asking for it. If your business runs its own backups, on one vendor or several, we can build the same kind of single view and morning report over them. It is a project engagement, scoped and quoted like any other build.

Free consultation

Tell us what you are stuck with.

We will tell you whether it is a build problem, a configuration problem, or something you should not spend money on at all.