appsignal

Monitoring Your App Without Running Your Own Prometheus Stack

Osinachi Okpara

Osinachi Okpara on

Monitoring Your App Without Running Your Own Prometheus Stack

Prometheus and Grafana are the default monitoring recommendations across DevOps blogs, Reddit, and Hacker News, and for good reason.

Prometheus is open-source and backed by the CNCF, but it’s not actually a complete monitoring system. It’s more of a metric collection engine. Deployment, configuration, and maintenance of several additional components are necessary to get from a running Prometheus instance to production-grade observability, and this involves a lot of real engineering time and infrastructure.

In this article, we’ll see what a Prometheus stack actually involves. We will also discuss where you can expect the costs to start showing up, and how you can get the same level of visibility with less operational overhead.

What Is a Prometheus Stack and Why Does Everyone Recommend It?

Prometheus target health dashboard
Prometheus target health dashboard - https://promlabs.com/blog/2024/09/11/a-look-at-the-new-prometheus-3-0-ui/

Prometheus is an open-source monitoring toolkit created by engineers at SoundCloud. It graduated from the Cloud Native Computing Foundation (CNCF) in August 2018.

Basically, it uses a pull-based model, which means that it scrapes metrics from your applications and services at regular intervals, usually from the /metrics endpoint. Then it stores them in a custom time-series database, and exposes them through its query language, PromQL.

One of the main reasons why it’s so popular is that it’s essentially free, and it has a large ecosystem of integrations. Plus, Kubernetes adopted it as its default monitoring solution; in fact, this is what actually made it the standard for anything cloud-native.

However, Prometheus alone covers only one part of a monitoring system. Metric collection, creating dashboards, alerting, long-term storage, and error tracking all require additional tools.

What a Production Setup Actually Looks Like

If you want to run Prometheus in production, the server itself is just the start. You'll also need:

  • Exporters to pull metrics from your services and infrastructure (Node Exporter, database exporters, custom app exporters, etc.);
  • Alertmanager for notifications, since Prometheus doesn't actually send alerts on its own;
  • Grafana for dashboards, because the built-in Prometheus UI is pretty basic;
  • Long-term storage like Thanos or Mimir, since its local storage isn't built for long retention;
  • Service discovery so Prometheus knows where your targets are as they scale or move around.
Prometheus stack in production
Prometheus stack in production

You’ve got six categories of software to wire together and keep running, and each of them comes with its own config format and upgrade cycle. Sure, this might be valuable as a learning exercise, but for production use, it's a lot to take on when you just want to know if your app is healthy.

The Hidden Costs of Running Your Own Stack

Self-hosted monitoring has some advantages. For starters, there’s no vendor lock-in and you get full control over your data. However, the trouble is that the total cost goes quite a bit beyond the $0 license fee, and it’s reflected in the infrastructure cost.

Prometheus' TSDB needs fast SSDs. Its memory usage grows linearly with active time series, and even a modest setup can easily chew up 8-16 GB of RAM. If you’re pulling in around 100,000 samples per second (fairly typical for mid-sized deployments), you're generating about 1.5 GB of compressed data on a daily basis. Six months of retention means roughly 270 GB of SSD storage just for metrics, before you factor in Grafana, Alertmanager, or your long-term storage backend.

Then there’s the engineering time. According to industry surveys, DevOps teams spend 20%-30% of their time on observability infrastructure. For example, a Salesforce team has reported spending a full engineer-day per month just on Thanos maintenance, and during this period, they had no time to build anything new.

In addition, Prometheus doesn't support native HA or horizontal scaling because it really was designed for single-node operations. So, when you outgrow one instance, you're adding Thanos, Cortex/Mimir, or Victoria Metrics on top, just to compensate.

Finally, your monitoring system itself can go down, and if Prometheus runs out of memory during a traffic spike, you lose visibility right when you need it most.

What You Actually Need vs. What Prometheus Gives You

Before we jump to alternatives, here are the four things that most apps require from monitoring:

  • Error tracking with enough context to enable you to solve the issue
  • Performance metrics broken down by endpoint to help you identify slow paths
  • Alerts that are routed to the right channel
  • Uptime checks from outside your infrastructure

Prometheus partially covers the second one, but you need separate tools for the rest. Therefore, you’ll likely end up running Grafana, Sentry, an uptime service, and maybe a log aggregator like Loki, each with its own setup and data store.

Getting the Same Insights Without the Overhead

So what’s it like to use a managed tool instead? AppSignal covers every piece of the stack I described above, but bundled into one product. You can see this clearly in the table below:

What You NeedPrometheus StackAppSignal
Metric collectionPrometheus server + exportersBuilt-in, automatic instrumentation
DashboardsGrafana (manual setup)Automated dashboards, ready on first deploy
AlertingAlertmanager + manually written rulesBuilt-in alerts with anomaly detection
Error tracking❌ (need Sentry or similar)✅ (with full stack traces)
Uptime monitoring❌ (need a separate tool)
Log management❌ (need Loki, ELK, etc.)
Host metricsNode Exporter + dashboardsIncluded automatically
Long-term storageThanos, Cortex, or MimirManaged for you

If latency spikes, you can trace it back to the exact error and stack trace without bouncing between half a dozen UIs. This type of correlation saves more time than any individual feature possibly could.

Setting It Up

Here's the Node.js setup (AppSignal also supports Ruby, Elixir, Python and more):

Shell
npx @appsignal/cli install

The CLI connects your app to your account. Then you add the initialization:

JavaScript
// app.js const { Appsignal } = require("@appsignal/nodejs"); const appsignal = new Appsignal({ active: true, name: "my-app", pushApiKey: process.env.APPSIGNAL_PUSH_API_KEY, });

With this simple set up, you can deploy and send traffic right away. Plus, it comes with automated dashboards where you can track request throughput, response times, and error rates. You can also easily spot slow routes, thanks to per-endpoint breakdowns, and you get full error tracking with stack traces grouped by root cause. On top of that, it provides a bunch of host metrics, including CPU, memory, disk, and network.

Now compare that to the Prometheus path. You'd be writing scrape configs, building Grafana dashboards by hand, deploying Node Exporter separately, and you still wouldn’t have error tracking or uptime checks.

AppSignal error dashboard
AppSignal error dashboard - https://www.appsignal.com/tour/errors

If you use AI coding tools, we also have an MCP server that brings your monitoring data right into your editor, which comes in quite handy when you want to debug without context-switching.

On Pricing

AppSignal's free plan includes 50,000 requests, 1 GB of logging, and 5-day retention. Paid plans start at €18.25/$23.25 per month when billed annually. Every plan includes unlimited users, teams, apps, and dashboards (no per-seat pricing).

Another good thing is that you won’t get hit with an upgrade the moment your traffic exceeds your plan limit. We only check after two or three months of overages, so no surprise invoices and uninterrupted monitoring. Plus, all data is stored in Europe by default, which is a big deal if you care about GDPR or data residency. Most US-based vendors charge enterprise rates for this.

When Self-Hosting Does Make Sense

Prometheus is the smart choice in some circumstances. For instance, if you’re dealing with hundreds of millions of samples a day, managed service pricing just doesn’t make sense. The same goes if you’re in an air-gapped environment with no outbound connections. It also works well when you have a dedicated platform team whose sole job is maintaining internal tooling.

But for everyone else, the question is whether managing all those components we walked through earlier is really the best use of their engineering time. Spoiler alert: it probably isn't.

Wrapping Up

When running Prometheus in production, you’re looking at half a dozen parts. Each of them comes with its own configuration and maintenance headaches, not to mention the hours your team will spend keeping the whole thing running.

Luckily, tools like AppSignal give you the full package in one go, with automated dashboards, signal correlation, and pricing you can actually predict. Self-hosting might make sense if you’re operating at massive scale or under tight restrictions, but for most teams, all this extra overhead just isn’t worth it.

If any of this has resonated with you, why not give AppSignal's free plan a try? No credit card is required, and setup takes about five minutes. It might save you a lot more time than you'd expect.

Wondering what you can do next?

Finished this article? Here are a few more things you can do:

Osinachi Okpara

Osinachi Okpara

Osinachi Okpara is a software engineer and developer advocate, with interests in AI engineering, cloud engineering, and open-source software. He is recognised as an AWS Community Builder.

All articles by Osinachi Okpara

Become our next author!

Find out more

AppSignal monitors your apps

AppSignal provides insights for Ruby, Rails, Elixir, Phoenix, Node.js, Express and many other frameworks and libraries. We are located in beautiful Amsterdam. We love stroopwafels. If you do too, let us know. We might send you some!

Discover AppSignal
AppSignal monitors your apps