No worries! Just checking. Yes we have backup 
I will also try the Nightly Builds… should I be looking at the 6.3 builds?
Good morning! I tried this build and the problem persists:
grafana-6.3.0-e0511f4apre.x86_64.rpm
Thanks!
6.3.0-7dfb512bpre worked! Thank you for your quick actions!!!
Yes that version is the first nightly with the fix of above issue.
Same! My displays are rolling again. Thank you!!!
This sounds really promising! Thanks a lot for living on the edge and trying out the beta 
It’s extremely valuable for us.
Is there any ETA on when this fix will be in a stable release (including a .deb
from packages.grafana.com) ?
I’m still seeing 6.1.6 as the latest stable.
Antony
Hmm, I’m still being logged out in 6.2.0
Hey, we’re also still facing this issue von 6.2.0.
When refreshing a dashboard, Grafana seemingly randomly logs the user out. The user is then dropped into the Grafana login screen.
Preliminary investigation show, that on a dashboard refresh, several queries are executed to /api/datasources/proxy/1/api/v1/query_range . This call returns a 401 , which in turn (why?) logs the user out of the session.
My gut feeling is, that this might have to do with too much load on Prometheus, causing the logout as an effect.
I’m still seeing it in 6.2.1 - it’s clearly not fixed.
5.4.4 works fine - I have a Raspberry driving a large-screen wallboard which
stays logged in for 24 hours (and auto-reboots every 3am) without any problem.
Grafana 6.x is unusable, because it logs the user out at random times, and the
wallboard has no keyboard / mouse to log back in again.
Even if it did (have a keyboard / mouse), this would be a workaround and not a
bug fix.
If any additional details are needed to help diagnose, please let me know (I
know various people reporting this have supplied various log file snippets, so
I don’t know if anything more or different is needed).
In case it’s relevant, Grafana 6.2.1 installed from .deb package on Debian 9.
Regards,
Antony.
I have implemented 6.3.0-7dfb512bpre in our test environment and am still getting timeouts.
When I refresh a page I get this error:
Possibly unhandled rejection: {“data”:{“message”:“Unauthorized”},“status”:401,“config”:{“method”:“GET”,“transformRequest”:[null],“transformResponse”:[null],“jsonpCallbackParam”:“callback”,“url”:“api/login/ping”,“retry”:1,“headers”:{“X-Grafana-Org-Id”:1,“Accept”:“application/json, text/plain, /”}},“statusText”:“Unauthorized”,“xhrStatus”:“complete”}
We’re experiencing the same issues after upgrading from 5.4.3 to 6.2.0.
Is there any news about this issue? It really renders are TVs unable to use Grafana.
I’m seeing this also, will investigate further. It appears that the auth token is being revoked before the client is notified.
This happens when the client cannot connect to the grafana server during token expiration.
So I can see a heap of status=401 messages and then a bunch of status=502 in the grafana log when my session timesout. I had a fiddle with the grafana.ini file and changed the login_maximum_inactive_lifetime and login_maximum_lifetime to 2 days. I also changed the token_rotation_interval_minutes to 720 (12 hours). This seems to have resolved my timeout issues. I do get booted once a day and I am guessing it is because of the token rotation. This is in v6.2.1.
Hey @latmanag, thanks for sharing this cool workaround.
What do you mean by “get booted once a day”? Does it mean logouts are still occurring or do are you referring to another kind of boot?
Hi @znavot, I think that because of the token rotation attempt after 12 hours, that my session is still timing out. If you extend it further, you may stay logged in longer. I want my users to have to log in once a day, so have set the token rotation to 12 hours.
Hi we’re experiencing this issue on 6.2.3 can anybody confirm that it was fixed in 6.2.4 or 6.3?
@latmanag 's workaround doesn’t seem to help
Still an issue as of 6.3.4…ours started when we upgraded to 6.3 (or became noticeably worse). It feels like the sessions aren’t actuall ybeing stored in the database as the documentation suggests they are by default.