ITLedger is a CMDB and IT operations platform with a ready structure, optional onboarding, connected service work, Sentinel and Richard AI assistance.

How does ITLedger onboarding work?

Customers send only the spreadsheets, exports or documentation they want loaded into ITLedger. We import that material, create relationships where the supplied information supports them, and let the customer review the result in the application.

What does ITLedger Sentinel show?

Sentinel brings findings from deliberately enrolled assets and active checks into one explainable attention queue. It supports certificate expiry, licence compliance, vulnerability exposure, external monitoring signals, source freshness, and explicitly mapped custom checks. Severity, thresholds, evidence, and operational impact remain visible.

Is onboarding credited when we subscribe?

Eligible paid onboarding can be credited against the first year of a qualifying annual subscription. Scope, eligibility, timing, and any non-creditable custom work are defined in the commercial proposal.

Is ITLedger always better than broad CMDB platforms?

No. Broad platforms may be better for deep global workflow customisation and organisations with dedicated platform teams. ITLedger is strongest when a lean team wants a working model and migration outcome without designing a large platform programme.

ITLedger Sentinel explained: an explainable attention queue for lean IT teams

Short answer

ITLedger Sentinel is an attention queue, not an autopilot. It collects findings from checks your team has deliberately enabled - certificate expiry, licence position, vulnerability exposure, external monitoring signals, source freshness and explicitly mapped custom checks - and keeps every finding linked to three things: the record it affects, the evidence behind it, and the threshold that triggered it. A finding in Sentinel is never a bare alert. It is a work item with an owner, a dependency context and a reason you can inspect.

Key takeaways

Sentinel only reports on assets and checks your team has consciously enrolled. Coverage is a choice, not an assumption.
Every finding stays explainable: which record, which evidence, which threshold.
Sentinel does not monitor every asset automatically, and it does not decide severity on its own. Your team sets the thresholds.
Because findings live inside the CMDB, they arrive with an owner and a dependency map attached - which is what makes them actionable.
The goal is fewer, better questions - "what needs attention first, and why" - not more notifications.

The problem: findings without context

Most IT teams already have signals. Certificates expire. Licence counts drift past purchased seats. Vulnerability feeds publish matches against your stack. Monitoring tools fire thresholds. The issue is rarely the absence of signals - it is that each signal arrives alone, in a different tool, without the context that makes it actionable.

A certificate warning that does not say which services depend on that certificate is a chore to investigate. A licence flag that does not name the application owner becomes an email chain. A vulnerability match without the asset's criticality is just noise with a CVE number. Teams respond the only way they can: spreadsheets of expiry dates, a calendar reminder, and a quiet hope that nothing important slips.

What Sentinel actually is

Sentinel starts from a deliberate decision: your team chooses which assets and which checks are enrolled. From that moment, findings from those checks land in one queue, and each finding keeps its context attached:

The record. The finding is linked to the actual configuration item - the certificate, application, server or licence record in your CMDB.
The evidence. The source data behind the finding remains visible, so you can verify instead of trust.
The threshold. The rule that fired is shown - for example, a 30-day warning window your team agreed, not a vendor default you never chose.

This is what "explainable" means in practice: when a finding says a certificate expires in 21 days, you can see which certificate, which applications it secures, who owns them, and which threshold produced the warning.

The checks Sentinel supports

Out of the box, Sentinel supports the finding types lean IT teams ask for most:

Certificate expiry - a certificate approaches the warning date your team configured.
Licence position - recorded demand rises above purchased capacity.
Vulnerability exposure - an enrolled asset matches the available vulnerability information.
External monitoring - a mapped monitor crosses the threshold your team agreed.
Source freshness - a record's source data grows older than your team expects.
Custom checks - explicitly mapped checks from your own sources, connected on purpose rather than guessed.

Each type follows the same rule: the finding names the record, shows the evidence, and states the threshold.

What Sentinel deliberately does not do

Sentinel is not a monitoring platform, and it does not pretend to be one. Three boundaries are worth stating plainly, because they are the difference between a queue people trust and one they learn to ignore.

First, Sentinel does not monitor every asset automatically. Enrolment is a conscious act - you decide what is worth attention. Second, it does not decide severity on its own. Thresholds come from your team's agreements, not from a black-box score. Third, coverage is exactly as broad as the records, checks, thresholds and external sources your team enables. Where coverage ends, Sentinel says nothing rather than implying safety.

These boundaries are deliberate. An attention queue works only if every item in it deserves to be there.

Why findings need a CMDB around them

A finding becomes work when it meets an owner and an impact radius. Because Sentinel findings live on top of the CMDB, a certificate finding already knows which applications that certificate secures, which team owns them, and which services depend on them. A licence finding names the application owner. A vulnerability finding can be weighed against what the asset actually supports.

That is the difference between "something somewhere needs attention" and "this certificate, on these applications, owned by this team, needs renewal before the 30-day threshold." The first produces anxiety. The second produces a ticket with an assignee.

How to start with Sentinel

Start narrow. Enrol the assets where an unnoticed finding would genuinely hurt - production certificates, licensed applications with real seat pressure, the servers behind your most important services. Agree thresholds with the people who will act on them. Then let the queue prove itself for a few weeks before widening coverage. A small queue that is always right beats a large queue that is sometimes wrong.

Sentinel is part of the ITLedger platform, so findings, records, owners and dependencies share one operating context. See the ITLedger features for the wider product view, or read how onboarding works if your asset data still lives in spreadsheets.

FAQ

Does ITLedger Sentinel monitor all assets automatically?

No. Sentinel reports only on assets and checks your team has deliberately enrolled. Coverage depends on the records, checks, thresholds and external sources you enable - that is a design choice, so every finding in the queue deserves attention.

Who decides what counts as severe in Sentinel?

Your team does. Thresholds - such as a 30-day certificate warning window or an agreed monitoring limit - are configured by you. Sentinel shows which threshold triggered a finding; it does not invent severity on its own.

Which checks does Sentinel support?

Certificate expiry, licence position, vulnerability exposure, external monitoring signals, source freshness, and explicitly mapped custom checks from your own sources.

What makes a Sentinel finding different from a monitoring alert?

Each finding stays linked to the affected CMDB record, the evidence behind it, and the threshold that triggered it - so it arrives with an owner and dependency context attached, ready to become work instead of noise.