Go to Vaultwarden Admin Diagnostics (/admin/diagnostics) and check the values for Date & Time (UTC). The values look like this:
NTP: Unable to fetch NTP time.
Server: 2025-04-23 18:19:18 UTC
Browser: 2025-04-23 18:19:26 UTC
In addition, there is a time difference between the server and the server and the browser of about 8-10 seconds. However, the difference is not correct, which I have checked manually.
Expected Result
Correct display of the NTP server time.
Actual Result
The page loading is delayed for ~10 seconds and the NTP source states NTP: Unable to fetch NTP time.
Logs
None
Screenshots or Videos
None
Additional Context
This is only a cosmetic problem. I have recently noticed that the NTP server time cannot be read out on the diagnostics page in the admin panel. With other servers, I have noticed very irregular and often long loading times of 30 seconds at timeapi.io. Does the API generally seem to be somewhat overloaded?
Originally created by @mrclschstr on GitHub (Apr 23, 2025).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/5797
Originally assigned to: @BlackDex on GitHub.
### Vaultwarden Support String
### Your environment (Generated via diagnostics page)
* Vaultwarden version: v1.33.2
* Web-vault version: v2025.1.1
* OS/Arch: linux/x86_64
* Running within a container: true (Base: Debian)
* Database type: MySQL
* Database version: 10.11.11-MariaDB-ubu2204
* Environment settings overridden!: true
* Uses a reverse proxy: true
* IP Header check: true (X-Real-IP)
* Internet access: true
* Internet access via a proxy: false
* DNS Check: true
* Browser/Server Time Check: true
* Server/NTP Time Check: n/a
* Domain Configuration Check: true
* HTTPS Check: true
* Websocket Check: true
* HTTP Response Checks: true
### Config & Details (Generated via diagnostics page)
<details><summary>Show Config & Details</summary>
**Environment settings which are overridden:** DOMAIN, ADMIN_TOKEN
**Config:**
```json
{
"_duo_akey": null,
"_enable_duo": false,
"_enable_email_2fa": true,
"_enable_smtp": true,
"_enable_yubico": true,
"_icon_service_csp": "",
"_icon_service_url": "",
"_ip_header_enabled": true,
"_max_note_size": 10000,
"_smtp_img_src": "***:",
"admin_ratelimit_max_burst": 3,
"admin_ratelimit_seconds": 300,
"admin_session_lifetime": 20,
"admin_token": "***",
"allowed_connect_src": "",
"allowed_iframe_ancestors": "",
"attachments_folder": "data/attachments",
"auth_request_purge_schedule": "30 * * * * *",
"authenticator_disable_time_drift": false,
"data_folder": "data",
"database_conn_init": "",
"database_max_conns": 10,
"database_timeout": 30,
"database_url": "*****://************************************************",
"db_connection_retries": 15,
"disable_2fa_remember": false,
"disable_admin_token": false,
"disable_icon_download": false,
"domain": "*****://**************",
"domain_origin": "*****://**************",
"domain_path": "",
"domain_set": true,
"duo_context_purge_schedule": "30 * * * * *",
"duo_host": null,
"duo_ikey": null,
"duo_skey": null,
"duo_use_iframe": false,
"email_2fa_auto_fallback": false,
"email_2fa_enforce_on_verified_invite": false,
"email_attempts_limit": 3,
"email_change_allowed": true,
"email_expiration_time": 600,
"email_token_size": 6,
"emergency_access_allowed": true,
"emergency_notification_reminder_schedule": "0 3 * * * *",
"emergency_request_timeout_schedule": "0 7 * * * *",
"enable_db_wal": true,
"enable_websocket": true,
"enforce_single_org_with_reset_pw_policy": false,
"event_cleanup_schedule": "0 10 0 * * *",
"events_days_retain": null,
"experimental_client_feature_flags": "fido2-vault-credentials,ssh-key-vault-item,ssh-agent",
"extended_logging": true,
"helo_name": null,
"hibp_api_key": null,
"http_request_block_non_global_ips": true,
"http_request_block_regex": null,
"icon_blacklist_non_global_ips": true,
"icon_blacklist_regex": null,
"icon_cache_folder": "data/icon_cache",
"icon_cache_negttl": 259200,
"icon_cache_ttl": 2592000,
"icon_download_timeout": 10,
"icon_redirect_code": 302,
"icon_service": "internal",
"incomplete_2fa_schedule": "30 * * * * *",
"incomplete_2fa_time_limit": 3,
"increase_note_size_limit": false,
"invitation_expiration_hours": 120,
"invitation_org_name": "Vaultwarden",
"invitations_allowed": false,
"ip_header": "X-Real-IP",
"job_poll_interval_ms": 30000,
"log_file": null,
"log_level": "info",
"log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
"login_ratelimit_max_burst": 10,
"login_ratelimit_seconds": 60,
"org_attachment_limit": null,
"org_creation_users": "",
"org_events_enabled": false,
"org_groups_enabled": false,
"password_hints_allowed": true,
"password_iterations": 350000,
"push_enabled": true,
"push_identity_uri": "https://identity.bitwarden.com",
"push_installation_id": "***",
"push_installation_key": "***",
"push_relay_uri": "https://push.bitwarden.com",
"reload_templates": false,
"require_device_email": false,
"rsa_key_filename": "data/rsa_key",
"send_purge_schedule": "0 5 * * * *",
"sendmail_command": null,
"sends_allowed": true,
"sends_folder": "data/sends",
"show_password_hint": false,
"signups_allowed": false,
"signups_domains_whitelist": "",
"signups_verify": true,
"signups_verify_resend_limit": 6,
"signups_verify_resend_time": 3600,
"smtp_accept_invalid_certs": false,
"smtp_accept_invalid_hostnames": false,
"smtp_auth_mechanism": null,
"smtp_debug": false,
"smtp_embed_images": true,
"smtp_explicit_tls": null,
"smtp_from": "****************",
"smtp_from_name": "Vaultwarden",
"smtp_host": "*************",
"smtp_password": "***",
"smtp_port": 587,
"smtp_security": "starttls",
"smtp_ssl": null,
"smtp_timeout": 15,
"smtp_username": "****************",
"templates_folder": "data/templates",
"tmp_folder": "data/tmp",
"trash_auto_delete_days": null,
"trash_purge_schedule": "0 5 0 * * *",
"use_sendmail": false,
"use_syslog": false,
"user_attachment_limit": null,
"user_send_limit": null,
"web_vault_enabled": true,
"web_vault_folder": "web-vault/",
"yubico_client_id": "67759",
"yubico_secret_key": "***",
"yubico_server": null
}
```
</details>
### Vaultwarden Build Version
v1.33.2
### Deployment method
Official Container Image
### Custom deployment method
_No response_
### Reverse Proxy
Traefik v3.3.5
### Host/Server Operating System
Linux
### Operating System Version
Ubuntu 22.04
### Clients
Web Vault
### Client Version
_No response_
### Steps To Reproduce
Go to Vaultwarden Admin Diagnostics (`/admin/diagnostics`) and check the values for `Date & Time (UTC)`. The values look like this:
```
NTP: Unable to fetch NTP time.
Server: 2025-04-23 18:19:18 UTC
Browser: 2025-04-23 18:19:26 UTC
```
In addition, there is a time difference between the server and the server and the browser of about 8-10 seconds. However, the difference is not correct, which I have checked manually.
### Expected Result
Correct display of the NTP server time.
### Actual Result
The page loading is delayed for ~10 seconds and the NTP source states `NTP: Unable to fetch NTP time`.
### Logs
```text
None
```
### Screenshots or Videos
None
### Additional Context
This is only a cosmetic problem. I have recently noticed that the NTP server time cannot be read out on the diagnostics page in the admin panel. With other servers, I have noticed very irregular and often long loading times of 30 seconds at `timeapi.io`. Does the API generally seem to be somewhat overloaded?
GiteaMirror
added the bug label 2026-06-17 09:23:25 -05:00
Is this always? Or is it works sometimes?
Because the loading time of the diagnostic page isn't only because of the timeapi.io but also github etc...
But, it it's only timeapi.io, it might be a good thing to try and switch to Cloudflare's cdn trace option.
<!-- gh-comment-id:2825326381 -->
@BlackDex commented on GitHub (Apr 23, 2025):
Is this always? Or is it works sometimes?
Because the loading time of the diagnostic page isn't only because of the timeapi.io but also github etc...
But, it it's only timeapi.io, it might be a good thing to try and switch to Cloudflare's cdn trace option.
I cannot 100% confirm that it is exclusively due to timeapi.io. Sometimes the retrieval of the NTP server time works. I would estimate that one in five page views can retrieve the time.
I've just noticed lately that it has gotten worse and worse. A few months ago I didn't notice any such problems and my setup hasn't changed in terms of the basic structure.
<!-- gh-comment-id:2825385169 -->
@mrclschstr commented on GitHub (Apr 23, 2025):
I cannot 100% confirm that it is exclusively due to timeapi.io. Sometimes the retrieval of the NTP server time works. I would estimate that one in five page views can retrieve the time.
I've just noticed lately that it has gotten worse and worse. A few months ago I didn't notice any such problems and my setup hasn't changed in terms of the basic structure.
As I already tried to describe in the issue description: A simple curl call to the timeapi.io API URL sometimes takes up to 30 seconds from various of my servers. I therefore assumed that timeapi.io triggers the delay in the admin panel.
<!-- gh-comment-id:2825402337 -->
@mrclschstr commented on GitHub (Apr 23, 2025):
As I already tried to describe in the issue description: A simple `curl` call to the timeapi.io API URL sometimes takes up to 30 seconds from various of my servers. I therefore assumed that timeapi.io triggers the delay in the admin panel.
I suspect that timeapi.io has a performance issue. Just accessing the site via a browser takes a few seconds. Now imagine API routes being accessed simultaneously by a myriad of clients.
<!-- gh-comment-id:2831524597 -->
@tessus commented on GitHub (Apr 25, 2025):
I suspect that `timeapi.io` has a performance issue. Just accessing the site via a browser takes a few seconds. Now imagine API routes being accessed simultaneously by a myriad of clients.
Yep, I have received NTP: Unable to fetch NTP time. a few times over the past 2 weeks as well. timeapi.io is completely overwhelmed. It might be a good idea to query an ntp pool instead.
<!-- gh-comment-id:2837440695 -->
@tessus commented on GitHub (Apr 29, 2025):
Yep, I have received `NTP: Unable to fetch NTP time.` a few times over the past 2 weeks as well. `timeapi.io` is completely overwhelmed. It might be a good idea to query an ntp pool instead.
NTP isn't really an option i think. Mostly because HTTPS is allowed in most places and NTP might be blocked. But Cloudflare has a timestamp in UTC via there trace endpoint.
<!-- gh-comment-id:2837470866 -->
@BlackDex commented on GitHub (Apr 29, 2025):
NTP isn't really an option i think. Mostly because HTTPS is allowed in most places and NTP might be blocked. But Cloudflare has a timestamp in UTC via there trace endpoint.
https://cloudflare.com/cdn-cgi/trace
Although vaultwarden is mostly running on servers, which in almost every case I have encountered so far use NTP for time sync. Unless I am missing something.
<!-- gh-comment-id:2837495267 -->
@tessus commented on GitHub (Apr 29, 2025):
Cool, this might be an option then.
Although vaultwarden is mostly running on servers, which in almost every case I have encountered so far use NTP for time sync. Unless I am missing something.
Indeed: Date & Time (Local)
Server: 2025-04-30 16:10:12 +00:00
Date & Time (UTC) Server/Browser Ok
NTP: Unable to fetch NTP time.
Server: 2025-04-30 16:10:12 UTC
Browser: 2025-04-30 16:10:14 UTC
Anyone found out where the NTP server can be set?
Not that i need it since it's fetching the local system its time which has a valid NTP server allocated. (Dockerized)
<!-- gh-comment-id:2842561163 -->
@Mafiasource commented on GitHub (Apr 30, 2025):
Indeed: Date & Time (Local)
Server: 2025-04-30 16:10:12 +00:00
Date & Time (UTC) Server/Browser Ok
NTP: Unable to fetch NTP time.
Server: 2025-04-30 16:10:12 UTC
Browser: 2025-04-30 16:10:14 UTC
Anyone found out where the NTP server can be set?
Not that i need it since it's fetching the local system its time which has a valid NTP server allocated. (Dockerized)
You cannot configure an NTP server directly at vaultwarden. As I understand it, the diagnosis is intended to compare the time of the underlying server with an external NTP server.
<!-- gh-comment-id:2844105773 -->
@mrclschstr commented on GitHub (May 1, 2025):
> Anyone found out where the NTP server can be set?
You cannot configure an NTP server directly at vaultwarden. As I understand it, the diagnosis is intended to compare the time of the underlying server with an external NTP server.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @mrclschstr on GitHub (Apr 23, 2025).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/5797
Originally assigned to: @BlackDex on GitHub.
Vaultwarden Support String
Your environment (Generated via diagnostics page)
Config & Details (Generated via diagnostics page)
Show Config & Details
Environment settings which are overridden: DOMAIN, ADMIN_TOKEN
Config:
Vaultwarden Build Version
v1.33.2
Deployment method
Official Container Image
Custom deployment method
No response
Reverse Proxy
Traefik v3.3.5
Host/Server Operating System
Linux
Operating System Version
Ubuntu 22.04
Clients
Web Vault
Client Version
No response
Steps To Reproduce
Go to Vaultwarden Admin Diagnostics (
/admin/diagnostics) and check the values forDate & Time (UTC). The values look like this:In addition, there is a time difference between the server and the server and the browser of about 8-10 seconds. However, the difference is not correct, which I have checked manually.
Expected Result
Correct display of the NTP server time.
Actual Result
The page loading is delayed for ~10 seconds and the NTP source states
NTP: Unable to fetch NTP time.Logs
Screenshots or Videos
None
Additional Context
This is only a cosmetic problem. I have recently noticed that the NTP server time cannot be read out on the diagnostics page in the admin panel. With other servers, I have noticed very irregular and often long loading times of 30 seconds at
timeapi.io. Does the API generally seem to be somewhat overloaded?@BlackDex commented on GitHub (Apr 23, 2025):
Is this always? Or is it works sometimes?
Because the loading time of the diagnostic page isn't only because of the timeapi.io but also github etc...
But, it it's only timeapi.io, it might be a good thing to try and switch to Cloudflare's cdn trace option.
@mrclschstr commented on GitHub (Apr 23, 2025):
I cannot 100% confirm that it is exclusively due to timeapi.io. Sometimes the retrieval of the NTP server time works. I would estimate that one in five page views can retrieve the time.
I've just noticed lately that it has gotten worse and worse. A few months ago I didn't notice any such problems and my setup hasn't changed in terms of the basic structure.
@BlackDex commented on GitHub (Apr 23, 2025):
Thanks for the extra info!
@mrclschstr commented on GitHub (Apr 23, 2025):
As I already tried to describe in the issue description: A simple
curlcall to the timeapi.io API URL sometimes takes up to 30 seconds from various of my servers. I therefore assumed that timeapi.io triggers the delay in the admin panel.@tessus commented on GitHub (Apr 25, 2025):
I suspect that
timeapi.iohas a performance issue. Just accessing the site via a browser takes a few seconds. Now imagine API routes being accessed simultaneously by a myriad of clients.@tessus commented on GitHub (Apr 29, 2025):
Yep, I have received
NTP: Unable to fetch NTP time.a few times over the past 2 weeks as well.timeapi.iois completely overwhelmed. It might be a good idea to query an ntp pool instead.@BlackDex commented on GitHub (Apr 29, 2025):
NTP isn't really an option i think. Mostly because HTTPS is allowed in most places and NTP might be blocked. But Cloudflare has a timestamp in UTC via there trace endpoint.
https://cloudflare.com/cdn-cgi/trace
@tessus commented on GitHub (Apr 29, 2025):
Cool, this might be an option then.
Although vaultwarden is mostly running on servers, which in almost every case I have encountered so far use NTP for time sync. Unless I am missing something.
@Mafiasource commented on GitHub (Apr 30, 2025):
Indeed: Date & Time (Local)
Server: 2025-04-30 16:10:12 +00:00
Date & Time (UTC) Server/Browser Ok
NTP: Unable to fetch NTP time.
Server: 2025-04-30 16:10:12 UTC
Browser: 2025-04-30 16:10:14 UTC
Anyone found out where the NTP server can be set?
Not that i need it since it's fetching the local system its time which has a valid NTP server allocated. (Dockerized)
@Gerardv514 commented on GitHub (May 1, 2025):
I'm showing same issue.
@mrclschstr commented on GitHub (May 1, 2025):
You cannot configure an NTP server directly at vaultwarden. As I understand it, the diagnosis is intended to compare the time of the underlying server with an external NTP server.