Humanoid Robot Operating Hours: How to Read Runtime and Uptime Claims

The short answer

Humanoid robot operating hours are evidence of activity, not a complete reliability score. To compare two claims, a reader needs to know which robots contributed, when the clock ran, what task they performed, how much work was accepted, when people intervened, and which failures or maintenance periods were excluded.

Four public records show why the distinction matters:

• Agility Robotics says Digit v4 accumulated more than 65,000 hours of operation in real-world customer environments, but does not publish the fleet, site, task, schedule, intervention, or uptime breakdown behind that total.
• Figure reports more than 1,250 runtime hours for Figure 02 at BMW, alongside more than 90,000 parts and a weekday shift schedule. BMW separately confirms the task, plant, ten-month period, and vehicle-production context.
• Longcheer says AGIBOT G2 completed one uninterrupted eight-hour test without human intervention at a tablet inspection station.
• AGIBOT reports more than 64 cumulative hours during a six-day factory livestream across multiple robots, plus a separate downtime-loss claim whose method is not fully disclosed.

These numbers answer different questions. The 65,000-hour total indicates broad cumulative customer-environment activity. The Figure record connects runtime to one bounded production workflow and customer confirmation. Longcheer’s eight-hour result measures one intervention-free test. AGIBOT’s 64-hour total spans several robots during a public observation window.

None should be placed in one ranking without preserving its fleet, task, schedule, control, and reporting boundaries.

Start with a clock-state model

The phrase “operating hours” sounds precise, but public reports rarely use one shared definition. A robot can be powered on, connected, available, moving, waiting for material, charging, blocked by another machine, under remote control, stopped for safety, or down for repair. Each state answers a different operational question.

Use at least these time categories:

Time category	What it should mean	Main question it answers
Calendar time	Full elapsed reporting window	How long did the deployment exist?
Scheduled time	Time when the robot was expected to serve the workflow	What was the planned operating demand?
Powered time	Robot and required control system were on	Was the system energized and connected?
Available time	Robot could accept eligible work under the stated service rule	Could the workflow call on it?
Active time	Robot was executing an assigned process	How much time involved task execution?
Productive time	Robot was producing output that met acceptance rules	How much active time created accepted value?
Assisted time	A person or external operator controlled, corrected, or recovered the system	How much human control was required?
Planned downtime	Declared charging, inspection, update, or scheduled service	What unavailable time was expected?
Unplanned downtime	Fault, damage, unexpected repair, software failure, or unscheduled stop	What unavailable time was not planned?

A company can reasonably choose different labels. The nonnegotiable requirement is a state definition that prevents one interval from silently changing meaning between reports.

For example, a robot waiting for a tote may be available but not active. A robot moving under teleoperation may be active but not autonomous. A robot completing a cycle that fails quality inspection may be active but not productive. A charging period may be planned downtime, or it may sit outside the schedule entirely. Each choice can be valid if it is disclosed consistently.

Runtime, uptime, and utilization are not synonyms

Runtime is a duration

Runtime usually refers to accumulated time in a selected active state. It may describe motion time, task-execution time, controller-on time, or a broader powered interval. A report should state the exact trigger.

Cumulative runtime is especially easy to misread when it is summed across a fleet. Ten robots each contributing time can accumulate robot-hours much faster than one robot. Fleet-summed robot-hours do not reveal elapsed deployment duration unless robot count and overlap are known.

Uptime is a ratio

Uptime requires both an available-time numerator and an eligible scheduled-time denominator. A defensible report states:

1. which schedule was eligible;
2. what state counted as available;
3. which planned periods were excluded;
4. how partial degradation was handled;
5. whether upstream and downstream workflow stoppages affected the clock;
6. whether safety stops, remote recovery, and software restarts counted as unavailable.

A percentage without those rules cannot be reproduced. It also cannot be compared reliably with another vendor’s percentage.

Utilization measures use, not availability

Utilization usually relates active or productive time to available or scheduled time. A robot can have high uptime and low utilization if it is ready but receives little work. It can have high utilization but weak output quality if it stays busy repeating failed attempts.

Buyers therefore need utilization paired with accepted throughput and quality. Busy time is not automatically valuable time.

Reliability needs event evidence

Reliability concerns whether the system continues to meet a requirement over a stated period and operating condition. Hours help define exposure, but failures define the result.

A useful reliability record includes:

• failures by hardware, software, perception, control, network, and workflow cause;
• interventions, resets, fault clearances, and protective stops;
• mean and percentile time to recovery;
• planned and unplanned maintenance;
• replaced parts and recurring failure modes;
• accepted output before and after each event;
• hardware and software versions in service.

A large hour total with no event record can establish experience. It cannot establish a failure rate.

How many hours per day can a humanoid work?

There is no defensible universal daily operating-hours figure. The useful answer is specific to the robot generation, task, customer schedule, energy plan, recovery process, and accepted output. Battery endurance is not the same as daily service capacity. A shift schedule is not a measured productive-time total.

The public Figure record illustrates the distinction. In its November 19, 2025 deployment report, Figure describes an 11-month deployment, testing and subsequent full deployment, a 10-hour Monday-through-Friday shift, and more than 1,250 runtime hours. BMW’s June 25, 2026 customer account describes Figure 02 supporting production over ten months. Those are different reporting scopes. Neither record supplies the per-robot daily schedule and state ledger needed to calculate productive hours per day or uptime. Do not treat the entire program, its full-deployment phase, and a scheduled shift as one interchangeable interval.

For a buyer asking whether a robot can cover a particular shift, we recommend collecting three separate answers:

1. Energy endurance: how long the tested configuration can execute the stated duty cycle before charging or battery service, under the declared load and conditions.
2. Workflow coverage: when the complete service can accept eligible work, including any approved charging, replacement-unit, and recovery arrangements.
3. Accepted production: how much time and output meet the customer’s acceptance rule during the actual scheduled window.

A battery swap or a second unit may change workflow coverage. It does not make the original robot’s battery last longer, eliminate servicing work, or establish that the handover is safe and reliable. Require the vendor and site operator to explain the actual arrangement rather than assuming that a brochure endurance figure scales into continuous production. The humanoid purchasing guide separates product access and lifecycle costs from achieved deployment performance.

A worked daily clock ledger

The following is a hypothetical buyer worksheet, not a vendor result, benchmark, or industry average. Assume one robot is scheduled for ten hours. For reconciliation, each interval receives exactly one primary state. Human involvement and output quality are recorded as separate labels, not extra hours added to the same clock.

Primary state	Hours in the scheduled window	Interpretation in this example
Executing the assigned task	6.0	Includes accepted work and execution that does not yield accepted output
Ready but waiting for eligible material	1.5	Available under the example service rule, but not executing
Planned charging	1.0	Unavailable during the scheduled window
Unplanned fault and recovery	1.0	Unavailable until eligible work can resume
Planned inspection	0.5	Unavailable during the scheduled window
Total scheduled time	10.0	Every scheduled interval is counted once

Under the rule chosen for this example, available time includes execution and ready waiting. It is 7.5 hours, so availability over the original ten-hour schedule is 75%. Active-time utilization over that schedule is 60%. Active-time utilization over available time is 80%. The percentages differ because the denominators differ, not because the underlying shift changed.

Now assume that 5.0 of the 6.0 executing hours produced output meeting the acceptance rule. Productive time is 50% of scheduled time. That does not establish accepted units per hour. Count accepted units separately and keep their reporting window aligned with the time ledger. An hour of accepted work on one task need not have the same economic value as an hour on another task.

If a service agreement excludes the 1.5 hours of planned charging and inspection, its eligible denominator becomes 8.5 hours. The same 7.5 available hours then give approximately 88.2% availability under that exclusion rule. Nothing about the actual day improved. A buyer still received five productive hours under the assumed acceptance definition. Report both the full scheduled-window result and the exclusion-based measure, with the exact exclusions visible.

This example treats charging as unavailable and material waiting as available. Those are explicit worksheet rules, not a universal uptime standard. A different customer requirement can classify them differently. Keep the requirement fixed across comparison periods and explain any change.

Separate autonomy from the reconciled clock

Suppose 0.5 hours of execution in the example involved direct human control. Those assisted minutes are already inside the 6.0 executing hours. Do not add them to the ten-hour total. Nor should a report call the remaining time productive autonomous work without checking both the control and acceptance labels.

Use an interval record with start and end timestamps, robot identity, primary state, control mode, task, output disposition, and stop or recovery cause. Join operator attention and intervention events to it. A person may supervise several intervals or work on recovery while the robot is stopped. The intervention and handoff guide explains why direct control time and wider human attention are separate support measures.

Turn the daily ledger into a pilot decision

Collect the ledger for every declared pilot day, not only the cleanest shift. Keep each robot separate before producing fleet totals. Record version changes, task mix, planned shutdowns, missing logs, rejected work, and the baseline process. Missing intervals are unknown time, not successful operation.

Before the pilot starts, agree what the site needs: eligible work coverage, accepted throughput, recovery response, support labor, and safety acceptance. Then review the daily distribution and failure causes against that agreement. A shift that meets a mean target can still contain unacceptable outages or quality failures. Do not average incompatible tasks or software versions into an unexplained single figure.

Our recommendation is to make this ledger part of the 90-day pilot acceptance process. It can support a purchasing decision when the definitions and records are shared. It does not replace a site risk assessment, a contractual service commitment, or evidence of performance outside the tested conditions.

Four public claims, four evidence shapes

Digit: a large total with missing fleet denominators

Agility Robotics’ September 2026 registration statement says Digit v4 accumulated more than 65,000 hours of operation in real-world customer environments. The filing also says Digit v4 is deployed or committed for deployment across nine customer facilities.

The hour total is meaningful. It moves the public record beyond a demonstration and indicates substantial activity in customer environments. The filing is also a formal regulatory disclosure, which makes its wording more consequential than a casual social post.

The statement does not publish:

• how many robots contributed;
• which sites were active rather than committed;
• the start and end dates;
• hours by task, customer, robot, or software version;
• scheduled, available, active, productive, or assisted time;
• interventions, resets, downtime, maintenance, or safety events;
• customer confirmation of the aggregate.

The correct reading is narrow: Agility reports substantial cumulative Digit v4 customer-environment operation, but the total does not establish per-robot uptime, autonomous hours, throughput, or fleet reliability. Our Digit economics audit keeps this completed operating claim separate from Digit v5 release plans, commercial assumptions, and conditional orders.

Figure 02: runtime connected to task and customer context

Figure reports more than 1,250 runtime hours for Figure 02 at BMW Plant Spartanburg. The company also reports more than 90,000 sheet-metal parts loaded and operation during a 10-hour shift from Monday through Friday during full deployment.

BMW separately says Figure 02 supported production of more than 30,000 BMW X3 vehicles over ten months. Customer confirmation strengthens the record because it ties the work to a named plant, bounded task, duration, and production context.

The combination is stronger than runtime alone. It links time, output, task, and customer. Yet the sources still do not publish the robot count, completed versus attempted cycles, achieved placement-success distribution, interventions, scheduled uptime, maintenance, safety events, or commercial terms.

The schedule also should not be multiplied into an assumed uptime result. A 10-hour shift describes expected operating context. It does not prove that the robot was available or productive for every minute of every shift.

The Figure at BMW evidence audit preserves the difference between Figure 02’s completed production record and Figure 03’s separate logistics demonstration. Operating hours do not transfer automatically across hardware generations or tasks.

Longcheer and AGIBOT: one bounded test plus a broader fleet record

Longcheer says AGIBOT G2 completed an uninterrupted eight-hour test without human intervention at a tablet precision-testing station. That claim has useful boundaries: a named customer, site, task, duration, and human-intervention statement.

It remains one test. It does not establish the long-run intervention rate, maintenance burden, defect rate, or performance across different shifts and product conditions.

AGIBOT later reported more than 64 hours of multi-robot operation during a six-day factory livestream. The company also reported approximately 3,000 units per shift and downtime loss below 4 percent in a separate update.

These figures should remain separate:

• Longcheer’s eight hours cover one uninterrupted no-intervention test.
• AGIBOT’s 64 hours are cumulative across multiple robots during a wider observation period.
• The reported throughput lacks a published shift-length and accepted-output definition.
• The downtime-loss percentage lacks a complete calculation method, eligible schedule, and event list.

A bounded clean run is valuable evidence. It is not equivalent to a long-term uptime result.

A comparison that preserves the denominator

Public record	Time evidence	Strongest supporting context	Important missing fields
Digit v4	65,000+ hours in real-world customer environments	Company disclosure in an SEC filing	Fleet, sites, time window, schedule, autonomy, output, interventions, downtime, maintenance
Figure 02 at BMW	1,250+ runtime hours	Named task, 90,000+ parts, weekday shift context, BMW confirmation over ten months	Fleet, attempts, achieved success, interventions, uptime, maintenance, safety, terms
AGIBOT G2 at Longcheer	One uninterrupted 8-hour no-intervention test	Customer-confirmed task and production-line setting	Repeated shifts, fleet, failures, maintenance, quality, long-run intervention rate
AGIBOT G2 factory run	64+ cumulative hours across multiple robots	Six-day livestream and vendor operating update	Robot count, per-robot hours, full intervention record, schedule, accepted output, downtime method

This table is not a leaderboard. The reporting scopes differ too much. It shows what each claim adds and what a normalized comparison would still require.

The broader physical AI production comparison reaches the same conclusion across humanoid, wheeled, fixed-arm, and construction systems: cumulative activity is useful, but a rate requires fleet, time, output, and assistance denominators.

The minimum operating-hours evidence card

Before using an hours claim in a procurement or investment decision, reconstruct this card.

1. System boundary

Record the robot model and generation, hardware configuration, software version, controller, sensors, remote-operations system, and required site infrastructure. State whether the reported system includes the robot only or the complete workcell.

2. Fleet denominator

List the number of robots contributing hours. Keep per-robot hours, fleet-summed robot-hours, elapsed site time, and simultaneous operation separate. Report additions, removals, replacements, and retired units during the window.

3. Reporting window

Give start and end timestamps, time zone, working days, shift schedule, holidays, planned shutdowns, and customer production calendar. A cumulative lifetime total should also include a current-period breakdown so progress and regressions remain visible.

4. Task and acceptance rule

Define what the robot was assigned to do and what counted as accepted output. Include rejected work, partial completions, retries, damaged items, downstream inspection, and excluded task variants.

5. Clock states

Publish scheduled, powered, available, active, productive, assisted, charging, blocked, planned-down, and unplanned-down time. Ensure the states reconcile to the reporting window without double counting.

6. Control and human support

Report autonomous time separately from teleoperation, shared control, intervention, reset, fault clearance, maintenance, setup, and supervision. Human attention time matters even when direct control lasts only seconds.

The robot intervention guide explains why control seconds, attention time, recovery outcome, and later unassisted performance are distinct measures.

7. Failure and recovery

Count failures by category and severity. Report time to safe stop, diagnosis, restored availability, and accepted production. Preserve rare safety events instead of hiding them inside a favorable average. The recovery-access section of our intervention guide separates control handoffs from physical servicing and explains why isolation, verification, and return-to-service work should remain visible.

8. Output and quality

Pair hours with attempts, successful cycles, accepted units, cycle-time distribution, quality defects, and rework. Output per active hour and accepted output per scheduled hour answer different questions, so publish both when possible.

9. Customer confirmation

A customer should confirm the site, task, reporting window, acceptance rule, and relevant totals. Vendor and customer figures should be shown separately when their measurement systems differ.

10. Change history

Record every hardware replacement, software update, policy change, site modification, and metric-definition change. A deployment can improve over time, but the record should not blend incompatible versions into one unexplained lifetime average.

Common mistakes when comparing hours

Dividing totals from different scopes

Do not divide a lifetime output total by a recent runtime total unless the source confirms that the same robots, sites, tasks, and dates produced both numbers.

Treating fleet hours as elapsed time

Fleet-summed hours can grow in parallel. Without robot count and overlap, they do not establish how long one robot ran or how long the deployment lasted.

Calling all active time autonomous

Movement can include teleoperation, shared control, calibration, recovery, or engineering tests. Autonomous time needs its own control-state definition.

Converting a shift schedule into uptime

A stated shift is not proof of availability throughout the shift. Use timestamped state logs and the declared uptime rule.

Removing planned downtime without saying so

Excluding scheduled charging or maintenance may be reasonable for a service-level measure. A buyer still needs those periods to understand capacity and workflow design.

Treating intervention-free as support-free

A no-intervention run may still involve monitoring, setup, material preparation, safety oversight, or maintenance outside the task interval. Report direct control and wider support separately.

Blending generations

Operating experience can transfer to a company, but achieved reliability belongs to the tested hardware, software, task, and site. Digit v4 hours do not prove Digit v5 reliability. Figure 02 hours do not prove Figure 03 uptime.

A practical buyer worksheet

Ask the vendor and operator to fill one row for each robot, site, task, and software version.

Field	Required value
Reporting window	Start, end, time zone, eligible shifts
Robot identity	Unit ID, model, generation, configuration
Software identity	Release, policy, controller, safety configuration
Task	Input, action, accepted output, exclusions
Scheduled hours	Expected service hours in the window
Available hours	Hours meeting the declared availability rule
Active hours	Hours executing the workflow
Productive hours	Hours creating accepted output
Autonomous hours	Hours without direct human control
Assisted hours	Teleoperation, shared control, intervention, reset
Downtime	Planned and unplanned, with causes
Output	Attempts, accepted units, rejected units, rework
Reliability events	Failures, stops, recovery times, replaced parts
Human work	Monitoring, response, maintenance, integration, training
Customer sign-off	Named owner, method, date, exceptions

A useful pilot should collect this from the first day, not reconstruct it after a favorable result. Our 90-day humanoid pilot guide places these fields inside a staged customer acceptance and commercial decision process.

What stronger public reporting would look like

The next useful industry disclosure is not merely a larger cumulative number. It is a reconciled operating statement for one bounded workflow.

A strong report would publish:

1. the exact fleet and versions;
2. the customer site and task;
3. the reporting window and eligible schedule;
4. scheduled, available, active, productive, assisted, and down hours;
5. attempts, accepted output, defects, retries, and cycle-time percentiles;
6. interventions, teleoperation, resets, and operator attention;
7. failure categories, maintenance, replaced parts, and recovery time;
8. safety stops, incidents, near misses, and exclusions;
9. the baseline process and cost boundary;
10. customer confirmation and a consistent prior-period comparison.

This would make hours useful for three different readers. Engineers could diagnose reliability. Buyers could estimate capacity and support. Investors could connect deployed activity to service cost, customer acceptance, renewal, and revenue.

Bottom line

Operating hours matter because robots must survive contact with real workflows over time. A substantial hour total can show that a system moved beyond a selected demonstration. A task-linked runtime total can show recurring activity. An intervention-free shift can show one bounded period of autonomous execution.

The claim becomes decision-grade only when the clock is defined.

For every humanoid operating-hours claim, ask five questions: how many robots, over what schedule, doing which accepted work, with how much human help, and with which failures or maintenance included. Without those denominators, hours measure exposure, not uptime, autonomy, reliability, or economic value.

Update and source review

Updated October 13, 2026 with a daily operating-hours worksheet and a fresh review of the Figure and BMW sources cited above. The worksheet values are illustrative assumptions, not measured robot performance. The original September 29 evidence comparison is retained; other vendor records were not re-audited for this update.

Frequently asked questions

How many hours per day can a humanoid robot work?

There is no defensible universal daily figure. Battery endurance, the customer shift schedule, available time, active time, and accepted output are different measures. Request a per-robot daily ledger covering charging, waiting, faults, recovery, and accepted work. A reported 10-hour shift does not establish 10 productive or autonomous hours.

What are humanoid robot operating hours?

Operating hours are a time total reported for robot activity, but the term is not standardized. A useful disclosure defines when the clock starts and stops, whether hours are summed across robots, which sites and tasks are included, and whether setup, waiting, charging, intervention, and downtime count.

Is robot runtime the same as uptime?

No. Runtime usually records time when a system is powered, executing, or otherwise active. Uptime is a ratio that requires an eligible scheduled-time denominator and a clear rule for what counts as available. A cumulative runtime total cannot be converted into uptime without that schedule and state record.

Can operating hours prove that a humanoid robot is reliable?

They can show that meaningful activity occurred, especially when the task, customer, period, and hardware generation are clear. They do not establish reliability by themselves. Reliability also needs fleet size, failures, interventions, maintenance, recovery time, successful output, and excluded periods.

How should operating hours be normalized across a robot fleet?

Report robot-hours by individual robot, hardware generation, site, task, and software version. Keep fleet-summed hours separate from elapsed calendar time, and pair them with scheduled hours, available hours, productive hours, interventions, downtime, and accepted output.

What should a buyer request before accepting an uptime claim?

Request the eligible schedule, fleet and version list, timestamped state definitions, planned and unplanned downtime rules, intervention and maintenance logs, accepted-output criteria, exclusions, customer sign-off, and the raw totals used to calculate the percentage.