Hard limit of a time range for graphs

Hi, trying to force a limit on public graphs, so they ONLY show the last 24 hours. I’ve tried “Override relative time” and that works for the initial load, but it’s still possible for users to select their own time range in the bar at the top.

We have some items that are monitored every 10s, and people selecting a year would hammer our database to death.

Is there a way of locking this down? I’ve already seen that there’s no way to remove the time range buttons at the top (although that would help!)

We’re using the Zabbix API as a data source if that makes any difference.

Thanks for any help!

Grafana 4.2.2 on Debian


It is not currently possible but there is a feature request for it so you can track the progress. It would be a good feature to have in Grafana.

Thank you for the reply!

I’ll look at hiding the time range picker using a theme in the meantime as a stopgap.

@daniellee Feature request is still open. Is there any possibility of it completing soon.
@redbaron have you achieve this using any side way. Any help would be highly appreciated.

We have not received any pull requests for it and there are currently no plans for the core team to work on it.

I think it is very important for High Resolution data.
We are facing the same challenge.
It would be a great benefit if core team consider working on it.
@redbaron @vishaggarwal94 have you got any workaround for this?

I’d like to chime in and say I too would like to be able to limit the time range. I don’t need a user querying a years worth of dense data and causing my server to go up in flames.

What is your data source. You can bypass the time picker by picking your own time range in the qiery builder depending on the data source type

@yosiasz SQL Server, however I am not looking to really pick my own range, I’d just like to limit the users freedom with the time picker tool. For instance, if they want to look at some random week last year, they can use the time picker to do so, however if they want to pick last year in its entirety, prevent that from happening because that is too large of a data set.

It’d be nice if it were a feature in the dashboard settings to limit the maximum selectable time frame, with my record density, the server struggles to serve any timeframes greater than a week long.

1 Like

Calculate how many datapoints you have per week and add that counter as hardcoded limit to all your SQL queries. Users still can select own time ranges, but they won’t kill SQL server.
Or use time aggregation, where it makes sense.

1 Like

I would highly recommend you do not hit your oltp, if that is what you are doing. Also use stored procedure rather than inline sql queries.
Also you could create your own smart date ranges as variables so that you can control the
fromDate toDate ranges.
Also on the db side, do you have indices on the data columns you are filtering on? etc
Until this hard limit feature is implemented.

The below should not happen on a well tuned db

“server struggles to serve any timeframes greater than a week long”

The database is not a well tuned DB. I’m operating out of my normal job scope on this project. I typically don’t deal with databases and stick to manufacturing equipment code. I’ll take what you’ve said into consiseration and work on optimizing my code and database to the best of my abilities.

However, I still think the suggestion is a good one. A simple optional control limit on the front end can make a cleaner UI experience and prevent having to do all sorts of backend failsafes. It’s be useful especially for people like me who are not database wizards and are just trying to unify parts of a larger project.

Thanks for the input.

like this , then you have control over it and you dont get runaway queries.


Then you can make the second To drop down choice maybe to go only 2 weeks in. in fact you might not even need a To drop down choice, it can be calculated from the From variable


Hey Thanks! You’ve helped me before on other issues. I appreciate it. I look forward to trying out your solution when I get into work tommorow.

Thanks again.

1 Like