Read the observation
Retain the machine, component, value, unit and observation time. Check the age of the reading and record any missing source.
Predictive maintenance for computing systems.
Arcturus brings machine readings, operating history and inspection work together. Investigate a changing condition, give the inspection an owner and check a fresh reading after the work. Start with the servers, GPUs and storage your team operates.
Investigate the change on the machine.
A component’s temperature is rising. Begin with its identity, the time of the reading and the limit reported for that component. Compare the change with earlier observations from the same source and review the workload running at the time.
Arcturus retains the observations behind a finding so an operator can inspect the condition and record what happened next. A gap, counter reset or replacement source changes the comparison. Keeping that history visible helps the next operator understand why the inspection began.
Keep the observation and inspection together.
The operating record connects the machine condition to the person responsible for checking it.
Review the finding
Compare accepted readings from a continuous source. Keep the baseline and the observations that explain the change together.
Assign the inspection
Name the responsible operator and record the checks performed, the assessment and the work completed. Keep the original finding attached.
Check the follow-up
Compare a fresh observation from the expected source with the baseline. Retain a continuing condition after the inspection closes so the next action has an accurate starting point.
Establish which observations are available.
The native build reviewed October 2, 2026 has Linux and macOS observation paths. Equipment, interfaces and permissions determine coverage.
This build identifies observed conditions and changes. It does not provide calibrated failure probabilities, remaining-life estimates or a guaranteed warning horizon. Equipment integrations, hardware partnerships and additional sensor designs are part of the development plan.
Compute and services
CPU utilization, memory use and configured service state.
Components and GPUs
Exposed temperature, fan and power readings; available NVIDIA utilization, memory, temperature and power through device tooling.
Storage and network
Filesystem occupancy, supported read-only SMART/NVMe fields on Linux, and available network-interface state, speed and error counters.
Give the investigation a working environment.
Rubian provides commands, system inspection and named projects with source files, findings and session notes. Kestowv supplies the systems foundation and documented pilot interfaces for service operation. Arcturus applies that foundation to machine reliability.
An operator can retain the inventory, inspection notes and next action in the project record. The documentation identifies the commands and environment requirements for the supplied components.
Check the service after recovery.
When a finding involves a service, the investigation also needs its health result, recent errors and allowed recovery actions. The Kestowv pilot documents restart policies, finite retry budgets and an operator handoff when attempts are exhausted.
A recovery check confirms the active version, expected service state and a useful application response. Keep the before-and-after observations with the work record. Application data and database recovery follow the application’s own procedure.
Bring one operating problem to the first conversation.
Tell us which machines and services are involved, what changed and who owns the next action. Useful starting material includes the operating systems, accessible telemetry, a recent incident timeline and redacted logs. We establish the observation sources, access boundaries and operating responsibilities for a connected evaluation.
The Reliability Baseline Review offers a separate, defined starting point: one host and up to three services reviewed from supplied logs and configuration summaries. Its deliverables include a proposed baseline, prioritized failure scenarios, a recovery-test plan and written findings. Implementation and ongoing monitoring have their own agreed scope.
Discuss the machine and the condition.
Bring the observations you have and the maintenance decision you need to make.