Built-in Prometheus metrics are now live on Bahriya
Every application has its own definition of "healthy." HTTP 200s and process-alive checks tell you whether your container is running. They don't tell you whether your connection pool is saturated, your cache hit rate has cratered, or your request queue is backing up. For that, you need application-level metrics — and for most of the industry, that means Prometheus.
The problem has always been the infrastructure around it. You write ten lines of code to expose a /metrics endpoint in your application, and then you spend an afternoon setting up a Prometheus server, configuring scrape targets, sizing storage, and wiring up a dashboard tool. The metrics endpoint took five minutes. The infrastructure to actually use it took the rest of the day.
Starting today, Bahriya handles the infrastructure part. Tell us the port and path, and we'll scrape it, aggregate it, and show it to you in the console. No Prometheus server to run. No scrape configs to write. No time-series database to manage.
How it works
If your application exposes a Prometheus-compatible metrics endpoint — and most frameworks make this trivial — you configure two fields on your container:
- Prometheus port — the port inside your container that serves metrics (e.g.
9090, 2019, 9113)
- Prometheus path — the HTTP path to scrape (defaults to
/metrics)
That's it. On the next deployment, Bahriya starts collecting metrics from every running replica, across every region. A new Prometheus tab appears on your container's detail page in the console, showing every metric context your application exposes, charted over time, broken down by region.
Works for every container type
This isn't limited to HTTP containers. Worker containers — queue consumers, background processors, anything that doesn't serve public traffic — can expose a metrics port too. Your worker doesn't need a hostname or ingress; Bahriya scrapes it internally.
That means you get the same visibility into your background processing as your public-facing services. If your queue consumer is falling behind, you'll see it in the metrics before your users see it in the response times.
What you can see
The metrics that appear are entirely defined by your application. Whatever your /metrics endpoint returns, Bahriya collects and charts. Common examples:
- Web servers — active connections, request duration histograms, requests per second by status code
- FrankenPHP / PHP — busy threads, worker memory, garbage collection stats
- Queue workers — jobs processed, jobs failed, queue depth, processing time
- Database clients — connection pool utilisation, query duration, slow query counts
- Caches — hit rate, eviction rate, memory usage
- Custom business metrics — signups per minute, orders processed, API calls by tenant
If your framework already has a Prometheus integration (and most do — Laravel, Express, Spring Boot, Go's promhttp, Rails, Django, Phoenix — the list is long), you're usually one package install away from a working /metrics endpoint.
Why we built this
We've watched the same pattern for years. A team deploys a container, sets up health checks, and everything looks green. Then something goes wrong — not a crash, not a health check failure, just a slow degradation. Cache hit rate drops from 95% to 60%. Connection pool starts maxing out during peak hours. Background jobs start taking three times as long. The container is "healthy" the whole time. Health checks pass. The status page is green.
By the time anyone notices, customers are already complaining.
Application-level metrics catch these problems early. But the cost of setting up and maintaining the monitoring infrastructure means most small and mid-size teams skip it, or set it up once and let it rot. We wanted to eliminate that cost entirely.
You already have the metrics endpoint in your application. You've already done the hard part. Now Bahriya does the rest.
No extra charge
Prometheus metrics collection is included with every container. There's no metrics add-on, no per-metric pricing, no retention tier to choose. Configure the port, deploy, and the data starts flowing.
Getting started
In the console, open your container's settings, scroll to the Observability section, and enter your prometheus port and path. Save and deploy. The Prometheus tab will appear on the container's detail page once the first scrape completes.
With the Reis CLI:
observability:
prometheus_port: 9090
prometheus_path: /metrics
Add these fields under the observability: block in your container YAML and run reis container:apply.
If your application doesn't expose Prometheus metrics yet, here are some starting points:
- PHP (FrankenPHP) — FrankenPHP exposes metrics on port
2019 at /metrics out of the box. Set the prometheus port to 2019 and you're done.
- Node.js — install
prom-client, create a /metrics route, and expose it on a separate port.
- Go — import
prometheus/client_golang/prometheus/promhttp and serve the handler on a dedicated port.
- Python —
prometheus_client provides a WSGI app and a standalone HTTP server.
- Ruby / Rails —
prometheus-client gem with a Rack middleware or standalone exporter.
Read the full documentation: Prometheus Metrics
What's next
This is the first step in a broader observability story. Bahriya already gives you logs, events, resource metrics (CPU, memory, network), and health checks. Prometheus metrics add the application-level layer that ties it all together. We have more planned — but we'd rather ship what works today and hear what you need next.
