Uptimer
Uptime monitoring and response time analytics.
After running in prod for a day I was able to do some napkin math and determine that 1000 checks would end up using 32GB of database storage for a year. While that sounds crazy, it helped give insights on future scaling and data retention limits.
This is VERY early speculation that I don't need to do, but I always enjoy doing for some reason.
The MVP focus has helped me ignore the future storage issue and consider the current data storage as doing something that doens't scale
I tried really hard to focus on releasable MVP chunks. The initial release has the ability to add/edit/delete checks and runs the checks on a given schedule and logs the results.
That's it! This release was really to prove my model in terms of scheduling checks, storing the results, and aggregating some baseline metrics.
MVP 2 is going to be visuals with charting on a global dashboard and dashboard for each checks. Dashboard will contain aggregate stats.
MVP 3 is going to be notifications, this is a major rabbit hole which I why I am deferring till later.
Through my network I had a contact that needed uptime monitoring. Rather than direct them to pay a giant corporate behemoth or send money overseas I decided to build something to solve this.
While this definitely a case of NIH syndrome , I love to build stuff and the challenges that come with architecture and development.
My only goal is to be net profitable in 3 months.
1 Comment
I'd handle that issue by having a retention system that thins out the data based on age.
For example, the chance of a user needing to know what the response time was at 5.30am 4.5 months ago is very low - probably just storing a datapoint for the day would be fine.