Skip to content
  • There are no suggestions because the search field is empty.

Hours and Cycles Synchronization

Hours and cycles synchronization helps FlightLogger Maintenance receive aircraft usage data that can support maintenance planning and due tracking.

Aircraft usage is important because many maintenance requirements depend on flight hours, cycles, landings, or other configured counters. If usage data is missing or incorrect, maintenance status and due calculations may be incomplete or misleading.

This article explains how hours and cycles synchronization works and what to check when setting it up or troubleshooting it.

What hours and cycles are used for

Hours and cycles data can support:

  • Aircraft usage history
  • Current aircraft counters
  • Recurring maintenance
  • Usage-based due calculations
  • Maintenance forecasting
  • Aircraft maintenance status
  • AMP-related planning
  • Component and life-limited tracking, depending on setup

The exact impact depends on how your aircraft, flight logs, counters, and maintenance requirements are configured.

How hours and cycles sync fits the workflow

FlightLogger may provide aircraft usage data.

FlightLogger Maintenance uses that data as part of the maintenance workflow.

For example:

  1. Aircraft activity is recorded in FlightLogger.
  2. Hours, cycles, or landings are made available to FlightLogger Maintenance.
  3. FlightLogger Maintenance stores usage readings for the aircraft.
  4. Aircraft flight logs may be updated from those readings.
  5. Maintenance planning can use the updated usage values.

FlightLogger provides operational input. FlightLogger Maintenance applies maintenance rules and due logic.

API endpoints

The hours and cycles API supports:

  • Reading hours/cycles records for an aircraft
  • Creating hours/cycles records for an aircraft

The supported API endpoints are:

  • GET /api/v1/aircraft/{call_sign}/hours_cycles
  • POST /api/v1/aircraft/{call_sign}/hours_cycles

The integration must have the required OAuth scopes.

For example:

  • hours_cycles_read is required to read hours and cycles.
  • hours_cycles_write is required to create hours and cycles records.

Create-only writes

Hours and cycles writes are create-only.

This means the integration can create a new usage reading, but users should not assume that the same flow freely edits or overwrites existing records.

If a flight already exists, the system may skip the record instead of creating a duplicate.

This behavior helps protect usage history from being overwritten unintentionally.

Aircraft matching

Before hours and cycles can be synchronized, FlightLogger Maintenance must identify the correct aircraft.

The API can find aircraft using:

  • Call sign
  • Registration
  • Aircraft ID

In practice, consistent aircraft identifiers are essential.

If the aircraft cannot be found, the hours/cycles sync cannot apply the usage data to the correct aircraft.

Before troubleshooting missing usage data, confirm that the aircraft exists and is correctly identified.

Flight payload

Hours and cycles writes use a top-level flight payload.

The payload can include usage-related information such as:

  • Flight ID
  • Date
  • Landings
  • Engine cycles
  • Primary log start
  • Primary log end
  • Primary log duration
  • Secondary log start
  • Secondary log end
  • Secondary log duration
  • Tertiary log start
  • Tertiary log end
  • Tertiary log duration

The exact data depends on the integration and the aircraft’s configured logs.

Reading hours and cycles

When reading hours and cycles, the records are returned for a specific aircraft.

The records are ordered by reading date and reading time, with the newest records first.

The API can also filter by date range.

This can be useful when reviewing usage history or troubleshooting whether a specific period has been synchronized.

Pagination

Hours and cycles API results are paginated.

The API supports page and per-page parameters, with a maximum of 100 records per page.

This helps keep responses manageable when an aircraft has many usage records.

Reading date and reading time

Each hours/cycles record has a reading date and reading time.

The reading date can be derived from the reading time when needed.

This helps FlightLogger Maintenance organize usage readings chronologically.

Correct dates and times are important because maintenance forecasting and historical review depend on knowing when readings occurred.

Source

Hours and cycles records can have different sources.

Examples include:

  • FlightLogger sync
  • Manual entry
  • CSV import
  • API import

The source helps users understand where a reading came from.

This can be useful when troubleshooting differences between manually entered values, imported values, and synchronized values.

Flight logs and current values

FlightLogger Maintenance can store multiple aircraft flight logs.

Hours and cycles records can update the current values on matching aircraft flight logs.

This means the aircraft’s configured flight logs need to match the incoming usage data.

If a log is missing or named differently than expected, the current value may not update as intended.

Landings and cycles

Cycles may be represented through landings or engine cycle values, depending on setup and incoming data.

The aircraft’s current cycle value may be calculated from recorded hours/cycles entries.

If cycles appear incorrect, review the aircraft’s recorded usage history and the incoming payload.

Why setup matters

Hours and cycles synchronization depends on setup in several areas.

You should confirm:

  • Aircraft exists in FlightLogger Maintenance
  • Aircraft can be matched by call sign, registration, or ID
  • Flight logs are configured
  • Log names match expected incoming data
  • The integration has the required scopes
  • The payload contains the expected usage fields
  • Duplicate flights are handled as expected
  • Maintenance requirements reference the correct counters

If any of these are missing, usage-based maintenance planning may not behave as expected.

Before enabling or testing sync

Before relying on hours and cycles sync, prepare:

  • Aircraft list
  • Call signs and registrations
  • Current usage readings
  • Flight log configuration
  • Counter requirements
  • OAuth scopes
  • Sync configuration
  • A test aircraft or small test data set
  • A validation plan for expected readings

This helps catch setup problems before go-live.

How to verify synchronization

After sync is configured, verify that data appears correctly.

Check:

  • The correct aircraft was updated
  • The latest reading date is correct
  • Hours values appear as expected
  • Cycle or landing values appear as expected
  • Flight logs show current values
  • Maintenance status reflects the updated data where relevant
  • No unexpected duplicate records were created
  • Sync logs do not show errors

Verification should be done before users rely on the data for operational planning.

Common issues

If hours or cycles are not updating, check:

  • Is the aircraft matched correctly?
  • Does the aircraft have the expected call sign or registration?
  • Does the integration have hours_cycles_write scope?
  • Does the payload use the expected flight structure?
  • Does the flight already exist and get skipped?
  • Are the aircraft flight logs configured?
  • Do incoming log names match the aircraft logs?
  • Is the reading date correct?
  • Are sync logs showing an error?
  • Is the user looking at the correct account?

Most issues are caused by aircraft matching, missing flight logs, missing scopes, or unexpected payload values.

Relationship to maintenance planning

Hours and cycles do not create maintenance decisions by themselves.

They provide usage data.

FlightLogger Maintenance uses that usage data together with maintenance setup, recurring maintenance, AMP requirements, aircraft configuration, and other records.

This is why synchronized data should always be reviewed in context.

If the usage data is correct but maintenance status still looks wrong, review the maintenance setup, counter mappings, and due rules.

Best practices

  • Confirm aircraft matching before syncing usage.

  • Configure flight logs before relying on hours and cycles.

  • Use consistent log names.

  • Test with a small data set first.

  • Review sync logs after setup.

  • Check latest readings after sync.

  • Avoid manual corrections unless the process is clear.

  • Document how usage data should flow from FlightLogger.

  • Review due maintenance after initial sync.

  • Train planners to understand that missing usage data can affect maintenance status.

Summary

Hours and cycles synchronization brings aircraft usage data into FlightLogger Maintenance.

This data supports maintenance planning, due tracking, forecasting, and aircraft status. The integration can read usage records and create new records, but writes are create-only and should not be treated as unrestricted updates.

Correct aircraft matching, flight-log setup, OAuth scopes, and payload structure are essential for reliable synchronization.