Monitoring deployments are hard to manage as code
Monitoring operators want their configuration and state to fit into reproducible deployment workflows. The requests span storing Uptime Kuma data outside a local SQLite file, loading monitor definitions from a config file, and provisioning a Datadog Elastic Cloud integration through Terraform instead of configuring it manually. These requests are related, but they come from different tools and may need separate integrations; the evidence is also several years old, so current support should be checked.
For self-hosted monitoring operators and infrastructure-as-code teams. Mentioned from Nov 2021 to May 2023 on GitHub.
4 different people described this problem in 3 separate discussions.
- Indie fit
- 5.0/10
- Pain
- 5.5/10
- Frequency
- 5.8/10
- Willingness to pay
- 0.0/10
- Momentum
- 5.0/10
- Who pays
- Businesses
- Competition
- Medium
- Build difficulty
- Medium
What people said
Quoted word for word. Follow a link to read the whole discussion.
I would rather store my data on my existing database server because I have backup routines, etc, which will protect the data. I like to keep the dat a spearate from the app so I can just reinstall the app, point it at the correct database
I added primarily MySQL support because I wanted to deploy kuma to Google Cloud Run (docker on google cloud), which does not support writing to local files. Additionally I prefer having data stored in a traditional database, as having it in a SQLite file insde a continer seems like a black box to me
See what to build and who will buy it
- 2 product ideas with the smallest useful version and pricing
- 4 places to find your first customers
- 2 more quotes from people who have this problem
- Current workarounds, existing solutions and risks