Skip to content

Arcturus
Machine-level predictive maintenance.

Arcturus brings machine readings and operating history into an investigation. Review a changing condition, assign an inspection and compare a fresh reading after the work. Computing systems are the starting point; power, cooling and wider facility systems are the expansion path.

For compute facility operators, infrastructure owners and enterprise computing teams.

Discuss ArcturusTry the machine demo

Start with a paid Reliability Baseline Review

Read the available machine observations.

Arcturus’s current native build collects machine observations, retains their source and time, identifies conditions and changes, and carries findings into inspections with fresh follow-up. Linux and macOS observation paths are present; the equipment and available permissions determine coverage.

CPU, memory and service state

Review CPU utilization, memory use and the state of configured services together. Capacity and load explain operating pressure; they are not, by themselves, a component-health diagnosis.

Temperature, fans and component power

Read exposed sensor measurements with their component identity and available device limits. Review a sustained temperature rise against that component’s reported limit. Missing or unreadable sensors remain visible as gaps.

GPU observations

The current NVIDIA path reads available utilization, memory, temperature and power through device tooling. Other GPU inventory can be present without live telemetry. The supplied build and accessible equipment establish what an operator can inspect.

Storage capacity and device reports

Keep filesystem occupancy separate from device health. The Linux read-only device adapter can collect supported SMART and NVMe health, warning and wear fields when access is available. Reported counter changes support inspection; they do not establish a failure date.

Host network observations

Review available interface state, reported speed and error counters with their source and observation time. A counter increase or a link change needs a continuous baseline and the interface’s operating role before it can guide a response.

History and follow-up

Keep the finding, accepted observations, inspection owner, recorded checks and fresh follow-up together. Stale data and source replacement keep their meaning; completing an inspection does not silently clear a measured condition.

Current build reviewed October 2, 2026. These are observed conditions and changes. This build does not provide a calibrated failure probability, remaining-life estimate or guaranteed warning horizon. Equipment-specific support is established for the supplied build.

Follow up after the inspection.

Consider a component whose reported temperature keeps rising toward its own limit. The useful result is a record the operator can investigate and act on.

  1. Read the source. Identify the machine, component, reading, unit and observation time. Check that the source is current and the limit belongs to that component.
  2. Review the change. Compare accepted observations from a continuous source. Retain the readings behind the finding; a gap, changed source or reset requires a new baseline.
  3. Assign the inspection. Keep the finding and baseline with the responsible operator. Record the checks performed and the assessment instead of treating an acknowledgement as a repair.
  4. Collect a fresh follow-up. Review a new observation from the expected source beside the baseline. Preserve the outcome and any remaining condition with the machine.

Read the observation guide · Explore the machine demonstration workflow

Bring the equipment and the operating question.

Start with the machine inventory, operating systems, accessible telemetry, recent incident history and the decision your team needs to make. Identify which observations can be read, which services are affected and who owns the next action. The evaluation should establish equipment fit before the operating scope expands.

A connected machine evaluation

Native observers and the supplied Rubian/Kestowv environment provide the machine observation and inspection path. Access, supported interfaces and operating responsibility are established for that environment.

See the baseline work

The public product experience

The public machine and facility demonstrations use labeled sample data. Use them to inspect the investigation workflow and discuss the observations that matter to your team.

Explore Arcturus

The full facility direction

Networking, utility power, UPS/PDU, cooling and facility systems are the expansion path. Their equipment categories describe the model we are growing toward; a category is not a claim that every controller or sensor is integrated.

Follow the facility model

Engineering evidence

The product manuals explain observation and workflow behavior. The company’s JRuby deployment record establishes upstream systems-engineering adoption; it answers a different question from predictive-maintenance validation.

Read the upstream record

Where compute has to keep running.

Arcturus is for the teams keeping compute facilities running. The workloads differ. Understanding machine health and acting before a developing problem becomes an outage matters across all of them.

Facility systems in the development plan

A server depends on more than the components inside its chassis. Our full-stack Arcturus model follows those dependencies so machine health, facility conditions and maintenance decisions can share one operating picture.

First commercial scope

Computing systems

Servers, GPUs, memory and storage. Bring together the available component signals, workload context and operating history to understand developing problems and the preventive actions they call for.

Facility expansion

Network & optics

Extend the model into switches, links and optical paths, connecting a network condition to the machines and workloads it affects.

Facility expansion

Power chain

Follow dependencies from utility supply through UPS and PDU to the rack and machine, connecting power conditions to the machines and workloads they affect.

Facility expansion

Cooling & facility systems

Grow into chillers, CRAH and CDU, along with fire, leak and access dependencies. Connect a developing condition to the equipment, people and maintenance work involved.

Talk to our teamExplore Arcturus

We plan to extend Arcturus through equipment integrations, hardware partnerships and our own sensor designs.

Explore the operating model.

The model connects machine health, service state and operating history to observation, investigation and response. Read each stage with its linked operating guide.

The technology underneath
Arcturus operating modelState → context → action
Machine healthServices & workloadsOperating history
ArcturusPredictive maintenance

Start with what’s actually happening.

Bring machine identity, health observations and service behavior into the same operating context.

Machine observations

Keep the history with the condition.

Understand the host, the work it’s running and the dependencies around it before choosing a response.

The machine model

Make recovery an operating decision.

Connect evidence to permitted actions, recovery checks and a clear handoff when a person needs to take over.

Explore reliability & recovery

Conceptual operating model. Explore the interactive machine demo for a sample environment.

Read the operator manuals.

The manuals distinguish current demonstration behavior, supplied component interfaces and planned product scope. Use the guide that matches the environment you are evaluating.

Observation reference

Read the timestamp, unit and missing-data conventions used by the public demonstrations, including the limits of browser-local records.

Observations and evidence

Machine demonstration guide

Follow a sample host through inventory, an incident and an export. The guide explains which actions change local records and which observations remain fixed.

Machine operation

Technical foundation

Find the references for Rubian commands, workspaces and libraries, and the supplied Kestowv pilot interfaces for service operation and workload evaluation.

The technical foundation

Predictive-maintenance scope

Review the equipment domains in the product direction and the integration and release qualification needed before a supported deployment is claimed.

Predictive-maintenance model

Inspect the operating experience.

The browser demonstrations use invented sample hosts and local actions. They expose no private telemetry and control no real machine.

One machine, a complete incident

Inspect health, read the incident context and follow the available controls. Use the demo to discuss which observations and actions matter to your environment.

Open the machine demo

A connected facility

Follow a sample condition across equipment and responsibilities. The demonstration illustrates the operating model; deployment integrations and physical maintenance are defined in the engagement.

Open the data-center demo

Start with the machine
that needs attention.

Bring one host and up to three services. Start with a defined review of the health signals, restart behavior and recovery gaps.

These are scoped professional services, not Arcturus software licenses. Implementation, software access and ongoing support are agreed separately.

$750 USD · one time

Reliability Baseline Review

Review the health signals, restart behavior and recovery gaps of one host and up to three services before choosing a larger reliability engagement.

Read the scope & pay

Need Arcturus for your environment?

Talk to a person about the machines, access requirements, integrations and operating responsibility you need covered.

Discuss a scoped engagementCompare all technical engagements

Talk machine-level predictive maintenance.

Tell us which system you’re responsible for, what’s changing and what a useful result would look like.

Talk to our teamEmail us