# Troubleshooting (/docs/orbit-studios-resources/orbit-lib/troubleshooting)



# Troubleshooting [#troubleshooting]

<Accordions>
  <Accordion title="orbit-lib starts, but Orbit resources do not work">
    Confirm `orbit-lib` starts after framework, inventory, target, and `ox_lib` dependencies, and before other Orbit resources. Then check that `Config.Framework`, `Config.Inventory`, and `Config.TargetResource` match the resources actually running on the server. A typo here can make downstream resources fail even when `orbit-lib` itself starts.
  </Accordion>

  <Accordion title="Target interactions are missing">
    Check `Config.TargetResource` and make sure the selected target resource is started before `orbit-lib`. If you changed from `qb-target` to `ox_target`, update the config and restart `orbit-lib` plus the resource that creates the interaction zones.
  </Accordion>

  <Accordion title="Inventory exports are missing">
    Match `Config.Inventory`, `Config.CustomInventory`, and `Config.CustomExport` to the resource and export names that are actually running. Use built-in adapters like `ox_inventory` or `qb-inventory` where possible. Use `qb-like` or `ox-like` only when the custom inventory exposes compatible exports.
  </Accordion>

  <Accordion title="Notifications or progress bars do not show">
    Set `Config.Notify` and `Config.Progress` to a provider installed on the server. Use `ox_lib` or `orbit-dynamichud` only when those resources are running. If `orbit-dynamichud` is selected for notifications, confirm the HUD starts after `orbit-lib`.
  </Accordion>

  <Accordion title="Job or gang checks fail">
    Confirm `Config.Framework` matches the live framework and that job/gang names in dependent resources match the framework data. Standalone servers should configure `Config.Standalone.fetchJob` when access rules need real job data instead of the default unemployed job.
  </Accordion>
</Accordions>