How to Sync Windows Server Time for the Sky Mission Hub
The Sky Mission Hub uses signed requests with a short validity window. If the Windows clock on your FiveM server is too far ahead or behind, the API can reject a request even when your server's credentials are correct.
This guide shows you how to synchronize the Windows clock, check that it worked, and try the Mission Hub again.
Why the Mission Hub needs the correct time
Each outgoing Mission Hub request includes a signed timestamp from the machine running FXServer. The API checks that timestamp against its own clock. If the difference is too large, the request is rejected with expired_signature.
In the Mission Hub, you may see "Unable to load mission hub." The more specific expired_signature error may appear in the server log. That general loading message can have other causes too, so checking the clock is a troubleshooting step rather than a fix for every connection problem.
Before you start
You need administrator access to the Windows server and a reachable time source. Windows includes the Windows Time service and the w32tm tool, so no additional software is needed.
For a provider-managed VPS or virtual machine, follow your hosting provider's time-source requirements. If the clock repeatedly changes back, ask them to check the host's synchronization as well.
Step by step: synchronize Windows Server time
Run these commands on the Windows server, not in the FiveM console or txAdmin console.
Open PowerShell as administrator
Open the Windows Start menu, search for Windows PowerShell, right-click it, and select Run as administrator. Accept the Windows permission prompt if one appears.
Enable and start the Windows Time service
Run these commands one at a time:
Set-Service -Name W32Time -StartupType Automatic
Start-Service -Name W32Time
This starts the time service and configures it to start automatically. Starting the service alone does not prove that the clock has synchronized.
Check the current time source and status
w32tm /query /source
w32tm /query /status
Look for the selected Source and Last Successful Sync Time. On a standalone server, the source may be a public or hosting-provider NTP server. On a domain member, it will normally be a domain time source. A virtual machine may use a host integration provider.
Local CMOS Clock or Free-running System Clock does not confirm synchronization with an external source. A missing or old successful-sync time is also a reason to investigate.
Request a fresh synchronization
w32tm /resync /rediscover
Wait for the result, then query the status again:
w32tm /query /source
w32tm /query /status
If synchronization succeeds and the status shows the expected source and a recent successful-sync time, continue to Verify the result below. You can keep your existing working time source.
If a standalone server needs a time source
Use this section only for a standalone server without a working managed time source. A standalone server is one that is not joined to an Active Directory domain.
If your hosting provider specifies an NTP server, use their documented settings. Otherwise, you can configure Windows to use Microsoft's public time server:
w32tm /config /manualpeerlist:"time.windows.com,0x8" /syncfromflags:manual /update
Restart-Service -Name W32Time
w32tm /resync /rediscover
The 0x8 flag selects NTP client mode. Restarting W32Time here restarts the Windows time service; it does not restart FXServer.
Check the result:
w32tm /query /source
w32tm /query /status
Microsoft documents these configuration options in Windows Time service tools and settings.
Verify the result
Before returning to the game, confirm that:
- The resync command completed successfully.
- Source shows the time source you expect for this server.
- Last Successful Sync Time is recent.
You can also compare the clock with the NTP source you configured:
w32tm /stripchart /computer:time.windows.com /samples:5 /dataonly
If you use a different NTP server, replace time.windows.com with that server's address. This collects five offset samples and then stops. The offset is shown in seconds; a synchronized clock should be close to zero rather than minutes or hours away. Windows can correct some differences gradually, so check again if the offset is still settling.
/stripchart compares clocks; it does not synchronize them. It also uses a different UDP source port from the Windows Time service, so a successful comparison alone does not prove that W32Time can synchronize. Check the resync result and service status too.Try the Mission Hub again
Return to the Mission Hub and click "Try again", or close it and open it again. The next request uses a fresh timestamp from the corrected server clock.
A FiveM or resource restart is not normally needed just to pick up a corrected system time.
If the Hub still fails, check the latest server log. A persistent expired_signature means the server clock still needs investigation. Other errors, including invalid_signature, require their own diagnosis; synchronizing the clock does not resolve every authentication issue.
Troubleshooting
Access is denied
Close the current PowerShell window and reopen it with Run as administrator. An account with local administrator rights is required to change the time service settings.
The service has not been started
Run the service commands again in an elevated PowerShell window:
Set-Service -Name W32Time -StartupType Automatic
Start-Service -Name W32Time
Get-Service -Name W32Time
The service status should be Running. Then repeat the resync command. If a managed policy disables the service or overrides its settings, ask your administrator or hosting provider to check that policy.
No time data was available
This usually means Windows could not obtain a valid response from its time source. Check:
- The configured NTP hostname is spelled correctly and resolves through DNS.
- The time source is available and provides NTP responses.
- Windows Firewall, the provider firewall, and the network allow the NTP request and its response over UDP port 123.
For example, on a standalone server configured to use time.windows.com, check DNS resolution with:
Resolve-DnsName time.windows.com
A successful DNS lookup only confirms name resolution. It does not prove that NTP traffic can pass. Ask your provider to check UDP 123 if synchronization still fails; disabling the firewall is not necessary.
See Microsoft's guide to the "no time data was available" error for further checks.
The clock becomes incorrect again
Check that the Windows Time service stays running and can reach its source. On a virtual machine, the hypervisor or hosting provider may also influence the guest clock. Have the provider check the host time if it repeatedly overwrites the corrected guest time.
Keep automatic synchronization working rather than manually adjusting the clock whenever the Hub fails.
Related guide
See Scenario Creator and Hub for the Fire System's mission creation and sharing workflows.
ESX, QBCore and Qbox: Set Up Your Framework and Create Jobs
A practical FiveM starter guide: install your framework, create jobs and grades correctly, understand duty and boss access, and check that everything saves.
Using GitHub Desktop to Simplify FiveM Updates and Spot Every Change
A no-command-line guide for FiveM server owners: use GitHub Desktop to see exactly what changed in an update, keep your own config edits, and roll back instantly when something breaks.