Results and logs

The Stations view shows stations across projects with status filters for running, idle, offline, and error. Open a station to see its details, current activity, and test history.

Browse history and compare results

In HTF v0.1.5, station totals cover all matching runs in the selected period, independently of the history page size. The previous station summary counted a recent-run response limited to 100. Project Logs searches now cover the full history and keep coordinated lane reports together.

Station run history, project reports, and Test sequences show 10 rows by default. Choose 25 or 50 in Rows, then use Previous and Next above or below the list. Changing filters or page size returns the list to its first page. Opening a report preserves your history position.

The analytics date picker defaults to the last seven UTC calendar days, including today. Both selected dates are included; analytics accept up to 366 days per request. History can reach older records. Use Add filter for lane, test plan, revision, DUT prefix, sequence, or captured field. The selected filters are saved in the URL.

Open Analytics actions for Compare stations or Export CSV. The comparison export covers the full matching result, independently of pagination. Use View settings for operating hours, weekdays, and chart timezone. Date selection uses UTC; the chart timezone controls daily grouping and shift boundaries.

Compare the same test plan and comparable station configurations. Revision numbers belong to each station, so equal revision numbers do not establish equal YAML. Captured-field comparisons use verified values and require access to DUT records.

Availability and lane utilisation

The usage panel separates busy, idle, error, offline, and unknown time within the selected operating schedule. Uptime is online time divided by known time. Lane utilisation uses known configured lane capacity, including monitored offline and error time; parallel lanes contribute separately.

Collection begins when this feature is deployed. Older availability is not reconstructed from current station status or run counts, and missing monitoring coverage remains Unknown. Check coverage before comparing stations or shifts. Lane, dates, stations, and operating hours affect usage; plan, outcome, DUT, and revision filters affect the run cohort only.

Test sequences and retries

New submissions start an explicit test sequence. Retry continues that sequence, including after kiosk recovery; a normal new submission starts a new sequence even for the same DUT ID. Parallel lanes form one attempt.

Test quality and retests shows first-pass yield, retested sequences, passes after retest, and extra attempt time. First-pass yield is successful first attempts divided by assessed first attempts for sequences started in the selected period. Pending, unknown, or inaccessible first attempts are counted separately. Earlier failures remain part of the assessment when filtering for passed runs. Station and lane scope can limit which attempts are assessed.

Older repeated DUT/plan pairs are not automatically classified as retests. Use View runs in the station sequence table to inspect a sequence's runs; the sequence list has its own pagination and summary metrics cover the full matching population.

Investigate a failed DUT

1. Find the station and run using its DUT ID or time.
2. Open the run and identify the first stage that failed.
3. Read its result and captured DUT data together with the station and firmware context. Load full logs when you need detailed console output.
4. Check nearby station events for connection or hardware problems.
5. Fix the cause, then run a new test; preserve the original result as evidence.

The project Logs area supports inspection of detailed log entries. The result, stage details, and logs belong together: a pass or fail by itself rarely explains what happened on a jig.

Structured test reports

HTF v0.1.4 opens captured data first in station reports and loads full logs on demand. Coordinated tests combine the lane reports. Captured DUT data shows observations and their source; Some data could not be captured lists capture warnings or rejected data.

This report uses simulated data with no connected hardware. The modem stage passed, while the voltage stage failed and its observation is marked Unverified.

A capture warning or rejected snapshot does not turn a valid hardware pass into a failure. Treat capture completeness as a separate check and inspect the station's rejected report reason if evidence is missing. DUT capture history explains verified values, retests, search, and CSV export.

If a station is offline, check the station process and connection before attributing the missing run to a DUT. Troubleshooting lists the first checks.

Download logs across tests

1. Open Test data in the project sidebar and choose Logs.
2. Set the project, station, DUT, run, batch, lane, or date filters you need, then select Apply filters. Dates select run creation times and do not truncate the run's output.
3. Leave Log output empty for complete retained run logs, or select historical stage versions. Stage choices show station, plan/lane, configuration revision, last execution, and matching run count, including renamed stages.
4. Select Download .log for readable output grouped by run, or Download JSON for structured run metadata and output.

Downloads start at the beginning and retrieve every matching page, regardless of the preview page. They include all retained lines, including runs longer than 500 lines. Cancel download stops an export; editing the filter form takes effect after Apply filters. Export completed tests after their data has finished arriving for a stable result.

Stage output is identified from retained stage headers and log prefixes. Repeated blocks are included; stages with the same name at multiple indexes share an output section. Deleted or expired log lines cannot be recovered by an export. Reading logs requires the appropriate project access. For captured values, choose Captured key values and follow Export evidence.