Why We Switched from Better Stack to a Local Solution

We Liked Better Stack. Then We Did the Math.

Let us start with the honest part: Better Stack is a well-designed product. The uptime monitoring is reliable, the status pages look professional, and the incident management workflow is thoughtful. When we first set it up for our infrastructure consultancy, it felt like a significant step up from the patchwork of scripts and manual checks we had been using.

We ran Better Stack for about fourteen months. During that time, our infrastructure grew from eight services to around thirty, spread across two Kubernetes clusters, a handful of Vercel deployments, and a few standalone services on DigitalOcean. As our footprint expanded, three issues became impossible to ignore: the monthly cost was growing linearly with our infrastructure, all of our operational telemetry was being sent to a cloud we did not control, and we were paying for a subset of the monitoring capabilities we actually needed while missing others entirely.

This is the story of how we migrated away from Better Stack and what we learned in the process.

The Three Problems

1. Vendor Lock-in and Growing Costs

Better Stack's pricing is reasonable for what it offers. The Team plan runs around $85 per month for basic monitoring, and costs scale with the number of monitors, team members, and log volume. For our thirty-service setup with three team members, we were paying approximately $120 per month, or about 1,400 euros per year. That is not outrageous, but it was money spent on something we increasingly felt we could handle locally.

More importantly, we were accumulating configuration debt. Our status pages, incident timelines, on-call schedules, and monitoring rules all lived in Better Stack. The more we invested in the platform, the harder it became to consider leaving. That is vendor lock-in working as intended, and we wanted to get ahead of it before the switching cost became prohibitive.

2. Data Leaving the EU

As a German infrastructure consultancy working with European clients, we care about data sovereignty. Better Stack processes monitoring data in the cloud, which means our health check results, incident logs, and service metadata are stored on infrastructure we do not control. For some of our client engagements, this created awkward conversations about compliance.

We are not suggesting that Better Stack is irresponsible with data. They are not. But for our use case, having the ability to point to a fully local monitoring setup where no operational data leaves the building was a genuine business advantage.

3. Feature Gaps and Feature Overlap

Better Stack excels at HTTP uptime monitoring and status pages but does not offer Kubernetes management, deployment tracking across providers, or real-time log streaming from pods. We were supplementing Better Stack with kubectl for cluster management, manual deployment tracking in a spreadsheet, and stern for log streaming. Meanwhile, we were paying for Better Stack features we barely used, like their incident escalation chains designed for larger teams.

The mismatch between what we were paying for and what we actually needed became the trigger for evaluating alternatives.

How We Replaced Each Feature

We did not migrate everything overnight. It was a gradual process over about three weeks, running both systems in parallel until we were confident nothing was falling through the cracks.

Status Pages

Better Stack's status pages were one of the features we used most. They are clean, customizable, and give clients a URL to check during incidents. Replacing this required CPI-Control's monitoring agent, a lightweight Go binary that runs on a server and serves branded status pages. The agent communicates with the CPI-Control desktop app over a secure connection and receives service health data to display.

The setup took about fifteen minutes: deploy the agent on a small server, point a subdomain at it, and configure which services to expose on the status page. The result is functionally equivalent to what Better Stack provided, with the added benefit that we control the infrastructure hosting it.

Uptime Monitoring

Better Stack's heartbeat monitoring and HTTP checks were replaced by CPI-Control's built-in health monitoring. CPI-Control automatically discovers services through its provider integrations (Kubernetes, Vercel, GitHub, DigitalOcean) and monitors their health status. For Kubernetes services, it watches pod status, resource usage, and events. For external services, it performs health checks based on the configured endpoints.

The transition was seamless because CPI-Control's service discovery is automatic. Once we connected our clusters and providers, CPI-Control picked up all our services and started monitoring them without manual configuration. We did not have to recreate thirty individual monitors.

Incident Management

Better Stack's incident management includes an incident timeline, status updates, and team notifications. CPI-Control handles this differently. It automatically detects incidents when service health changes, records the timeline locally, and sends push notifications through the desktop app. The notification system supports both in-app toast notifications and system-level notifications through the Notification API.

We lost Better Stack's incident update broadcasting to stakeholders, but we gained something arguably more useful: automatic incident detection that does not require someone to manually create an incident. When a Kubernetes pod starts crash-looping, CPI-Control detects it immediately, creates an incident entry, and notifies the relevant team member. With Better Stack, we first had to be alerted that the health check was failing, then manually create an incident, then update it as we worked through the resolution.

What We Gained

• Full data ownership: All monitoring data, health check results, incident history, and service metadata is stored locally in a SQLite database on our machines. Nothing leaves our infrastructure. When a client asks where their monitoring data is stored, the answer is "on the engineer's laptop, nowhere else."
• Zero monthly costs: CPI-Control is free for up to 50 services. Our annual monitoring bill went from roughly 1,400 euros to zero. Over a five-year horizon, that is 7,000 euros saved, which is meaningful for a small consultancy.
• Faster data access: Querying local data is inherently faster than making API calls to a cloud service. Health status, deployment history, and logs are available instantly rather than waiting for a round trip to Better Stack's servers.
• Unified operational view: Instead of Better Stack for uptime plus kubectl for Kubernetes plus manual tracking for deployments, we have a single application that covers all three. The context switching reduction alone was worth the migration.
• Kubernetes management: This was a net new capability. Better Stack does not manage Kubernetes resources. CPI-Control gives us pod management, resource metrics, events, and terminal access alongside the monitoring features. We retired our separate Kubernetes dashboard.

What We Lost

We would not be honest if we did not acknowledge the trade-offs.

• Managed log storage: Better Stack includes log management with searchable, retained logs. CPI-Control streams logs in real-time via stern and buffers them in memory, but does not provide long-term log storage. If you need to search through logs from last week, you need a separate solution. For us, this was acceptable because we rarely needed historical logs and could always check the cluster directly when we did.
• Public incident pages with subscriber notifications: Better Stack's incident pages let users subscribe to updates via email. CPI-Control's status pages are public but do not include subscriber management. We solved this for our most critical client-facing services by adding a simple email notification through our existing communication channels, but it is a manual process rather than an automated one.
• Monitoring when offline: Because CPI-Control runs as a desktop app, monitoring only happens when the app is running on an engineer's machine. The monitoring agent handles status pages independently, but the full monitoring and notification pipeline requires the desktop app. Better Stack, being cloud-hosted, monitored 24/7 regardless. In practice, we have the desktop app running during work hours and the monitoring agent covers critical health checks around the clock.

When Better Stack Is Still Better

Not every team should make this switch. Better Stack remains the better choice in several scenarios:

• Pure SaaS teams with no Kubernetes: If your infrastructure is entirely managed services (Heroku, Railway, Render) with no Kubernetes, CPI-Control's strengths in cluster management are irrelevant. Better Stack's simple HTTP monitoring is exactly what you need.
• Teams that need managed log storage: If searching through historical logs is a daily activity for your team, Better Stack's integrated log management is genuinely valuable. CPI-Control's real-time streaming model is not a replacement for indexed, searchable log storage.
• Organizations requiring 24/7 monitoring without desktop dependency: If you need guaranteed monitoring that runs regardless of whether any team member has their laptop open, a cloud-hosted solution like Better Stack provides that reliability inherently.
• Teams with complex on-call rotations: Better Stack's on-call scheduling and escalation policies are designed for teams with multiple tiers of responders. CPI-Control's notification system is simpler and does not include on-call rotation management.

Final Thoughts

Switching monitoring tools is never a decision to take lightly. There is always a period of uncertainty where you are not sure if the new tool covers every edge case the old one handled. For us, the migration took three weeks of parallel running, and by the end of that period, we were confident that CPI-Control covered everything we actually used in Better Stack while adding Kubernetes management and deployment tracking we previously handled manually.

The annual savings are nice. The data sovereignty is a genuine business advantage. But the biggest win was consolidation. Instead of three separate tools for monitoring, Kubernetes management, and deployment tracking, we have one. That reduction in complexity is hard to put a price on, but every engineer on the team feels it daily.

If you are evaluating whether to make a similar switch, our advice is simple: install CPI-Control alongside your existing monitoring tool and run both for two weeks. It takes two minutes to set up and costs nothing. If it covers your needs, you will know within the first week. If it does not, you have lost nothing but a few minutes of setup time.