Resource → Facts

The Facts tab shows MisterShell’s normalized, pre-collected, vendor-neutral facts about a resource — structured data that the platform normalizes into the same shape regardless of the underlying vendor or OS. A route looks the same whether it came from a Cisco device, a Linux host, or a firewall; an interface is an interface.

Facts are collected in the background and stored, so reading them does not contact the device. They are a fast way to inspect the last collected configuration without opening a live session.

The tab carries a beta badge: fact coverage and accuracy are still developing across resource types. Check collection status and verify important values against the resource before relying on them.

The same tab is available on supported resources and location detail pages. Graphical-only resource types and Generic SSH do not expose Facts. At location scope it includes permitted resources at the location and its descendants, so you can browse one fact type across the whole site.

The tab appears only when an administrator has enabled Facts and you hold app.resources.read. On a resource page it appears directly in the tab strip, after Notes.

What facts cover

Facts are organized into categories — for example system identity (platform, DNS, NTP), the networking layers (interfaces, neighbors, VLANs and MAC tables, routing, ARP, VRFs), and databases (instance, storage, replication, principals). Each category contains one or more fact types.

The catalog is growing: new fact types are added over time, so treat the tree you see in the UI as the source of truth for what is currently knowable — not a fixed list. On a resource, the tree includes applicable fact types even when no observations are stored, so you can distinguish an empty successful collection from a failed or disabled one. At location scope, the tree shows fact types with stored observations in that scope. Categories and fact types are listed alphabetically.

Layout

The tab is split into two panes:

• Left — fact-type tree. Fact types grouped by category. Select one to load its data on the right.
• Right — fact data. How the data renders depends on the fact type:
  • Single-record facts (one value per resource, such as system platform) show a field/value card on a resource page, with nested tables and sub-objects laid out inline. At location scope the same fact type renders as a table, one row per resource.
  • Multi-record facts (such as interfaces, routes, or ARP entries) show a searchable, exportable table, one row per item.

Missing values appear as -. CSV exports leave those cells empty; the display placeholder is not exported. For AWS compute instances, RAM capacity is not collected and appears as a missing value.

Collection status

On a resource, a small dot before the fact name shows its collection status. Hover over it for the explanation; a successful collection does not add a separate Complete label.

Dot	Meaning
Green	Collection completed with observations.
Orange	Partial collection: some facts could not be collected. Available observations can still be read.
Red	Collection failed. Retained observations may be outdated.
Grey	A successful collection found no facts, collection is disabled, or its status is unknown. The tooltip distinguishes these cases.

None observed. means the collection succeeded and returned no observations. An empty failed, partial, disabled, or unknown collection instead states that no observations are stored and absence is not established. Do not interpret that empty view as proof that the resource has no matching configuration.

Collection status belongs to each fact type. Check it before relying on retained values, especially after a failed or partial collection. Location views combine stored observations across resources; inspect an individual resource to assess its collection status.

Point in time

Facts are versioned. On a resource page the view follows the Snapshot Selector: by default you see the latest collected values; pick an earlier snapshot to read the facts as they were at that moment, and an “As of …” caption appears to remind you which moment you are looking at.

Facts vs. live data

Facts are pre-collected, so they can lag the device between collection runs. They are the right tool for a quick, normalized, fleet-comparable answer. When you need the absolute freshest state — or a detail no fact type captures yet — open a live SSH / shell session or run an Action; the device itself is always the freshest source.

Common tasks

Browse a fact type

1. Open the Facts tab on a resource or location.
2. Pick a category in the left tree, then a fact type beneath it.
3. Read the field/value card (single-record) or table (multi-record) on the right.

Search and export a table

1. Select a multi-record fact type (for example, routes).
2. Type in the table’s search box to filter rows.
3. Use the table’s export control to download the visible rows.

Read facts as of an earlier time

1. On a resource page, pick an earlier snapshot in the Snapshot Selector.
2. The data updates to that moment, and an “As of …” caption confirms it.

Turning facts into compliance

Use Fact Policy rules to check whether collected facts meet your standards, such as synchronized NTP or an approved software version. The Compliance card on Summary shows the results over time.

Configuring which facts are collected

Which fact types are gathered for each resource type is an admin setting, not something you change here. See Manage → Configuration → Facts.

Permissions

• View facts: app.resources.read, within your allowed locations.
• View collection settings: app.facts.read.
• Configure which facts are collected: app.facts.write (see Manage → Configuration → Facts).
• Requires Facts to be enabled by an administrator.