ReportsHQ compared with building it yourself
A table, a cron job and a chart library is a weekend. The second year of it is not. An honest account of what you would end up maintaining.
The first version really is a weekend
An events table, an insert, a nightly aggregate and a chart library. Anyone reading this could ship it by Sunday, and for a single number on an internal page that is the correct decision. This page is not going to argue with that.
The second year is the part to price
Retention and pruning so the table does not become the largest thing in your database. Rollups, so a report over last year does not scan every row. Timezones, so the daily job does not double-count an hour twice a year. Then a share link somebody outside the company can open, which means auth, revocation, and a decision about caching.
Where building it wins
Anything specific to your business. If the report you need is a join across three of your own tables with rules only you know, no general tool will express it, and you should write the query.
Where this wins
Everything in the second paragraph is already written, tested and running. And if you decide later that you would rather own it, the source is public and you can.
The honest version
If your reporting needs are one number on one page, build it. That is genuinely a weekend and this would be overkill.
Start free