TCO key terms

Lightweight agent installed on each managed endpoint. It evaluates sensors to answer questions, receives content, and executes actions on behalf of the Tanium Server.

Central management component that stores configuration and content, coordinates questions and actions, and brokers communication between the console and Tanium Clients. Often deployed as a redundant pair for high availability.

Server role that hosts Tanium modules and the web-based Tanium Console. It works with the Tanium Server to deliver user interface, reporting, and solution-specific processing.

Communication model in which Tanium Clients exchange question results, files, and content with neighboring clients rather than each connecting directly to the server, reducing bandwidth and server load.

Ordered sequence of clients used to pass questions or files from one endpoint to the next. It lets large content distributions scale while keeping direct server-to-client traffic low.

A Tanium Client acting as a distribution point in a peer-to-peer tree. It aggregates results from and forwards content to the clients beneath it.

Browser-based interface for asking questions, reviewing results, deploying actions, and managing content. Users reach it through the Module Server.

Container that groups related content such as sensors, packages, and saved questions. Content sets can be assigned to roles so users only see and use approved content.

Security model that grants users permissions through roles, user groups, and content sets. It determines which questions, actions, and content a person can access.

Programmatic interface that lets external tools and scripts submit questions, read results, and run actions. Access is controlled with API tokens and account permissions.

A real-time request sent to targeted endpoints asking them to evaluate one or more sensors and return results. Questions are the primary way operators gather data in Tanium.

A condition applied to a question or its results that narrows the scope, such as restricting to a specific sensor value. Filters reduce the number of endpoints or rows returned.

Navigation from a summarized question result into the individual endpoints or rows behind a count. It lets operators see which machines make up an aggregate value.

Tabular display of question answers, with one row per endpoint or per returned value and one column per sensor. Rows can be sorted, filtered, and exported.

Indicates whether a question is still collecting answers or has finished. Open questions continue to update; closed questions show the final results at the time of asking.

Summarizing question results rather than listing every row, for example by counting endpoints, counting unique values, or summing a numeric sensor. Aggregates make large environments readable.

Selecting which endpoints a question or action applies to, using options such as all machines, a computer group, or a filter. Correct targeting limits scope and blast radius.

A command deployed from the console to run a package on targeted endpoints. Actions have a status that reports success, failure, or pending for each machine.

Reusable definition of work to run on an endpoint, including the command line and any files required. Packages are the building blocks that actions execute.

Named set of endpoints used as the target for actions. Action groups can be static or dynamically defined, and they simplify repeatable deployments.

Per-endpoint report of an action's progress and outcome, including states such as pending, running, completed, failed, or expired. It confirms whether the deployment worked.

Workflow control that requires a second operator or approver to authorize an action before it runs. Approvals reduce the risk of unintended changes in production.

An action configured to run at a future time or on a recurring schedule, rather than immediately. Schedules support maintenance windows and repeated operational tasks.

The command line or script that a package executes on the endpoint, optionally using parameters. It defines the actual work performed when an action runs.

A script or query that runs on the Tanium Client and returns a specific piece of information, such as installed software or an OS setting. Sensors provide the columns in question results.

A sensor that accepts input values at question time, letting one definition return different results depending on the parameters supplied. This avoids creating many near-duplicate sensors.

A question stored with its sensors, filters, and targeting so it can be re-run later or reused in dashboards, reports, and scheduled activities. Saved questions standardize recurring data collection.

A sensor written by an administrator to collect data that built-in content does not cover. It must be tested because it runs on every targeted endpoint.

A console view that arranges saved questions and panels into a single monitoring page. Dashboards refresh on a schedule and give at-a-glance visibility into the environment.

A saved output that presents question or trend data for review or distribution, often on a schedule. Reports are used to document compliance or operational status over time.

Historical record of how a sensor value changes over time, built from repeated question results. Trends show growth, drift, or improvement rather than a single snapshot.

An alert triggered when a monitored condition or threshold is met, delivered through the console or another channel. Notifications draw attention to issues without constant manual checking.

Module that streams question results and other data to external destinations such as files, databases, or ticketing systems on a schedule or trigger.

Saving question or report data to a file such as CSV for use outside the console. Exports are useful for auditing, sharing, and further analysis.

View of endpoint health that shows whether clients are installed, running, communicating, and up to date. It helps operators find machines that are not reporting.