Custom Metrics and Autoscaling in Porter
Porter now supports exporting custom metrics from your applications and using them for autoscaling. This guide explains how to configure these features.Configuring Metrics Scraping
Note: Metrics scraping is only available for web services. You can now configure Porter to scrape metrics from your application’s/metrics
endpoint. This is useful for:
- Collecting application-specific metrics
- Setting up custom autoscaling based on your metrics
- Monitoring application performance
How to Enable Metrics Scraping
- Navigate to your application dashboard
- Select your web service
- Go to the “Advanced” tab under service settings
- Find the “Metrics scraping” section
- Enable “Enable metrics scraping”
- Configure the following options:
- Port: The port where your metrics endpoint is exposed (defaults to your web service’s default port)
- Path: The path where metrics are exposed (defaults to
/metrics
)

Prometheus Metrics Format
Your application must expose metrics in Prometheus format, which follows these basic principles:- Metrics are exposed as HTTP endpoints (typically
/metrics
) - Each metric follows the format:
metric_name{label1="value1",label2="value2"} value
- Common metric types:
- Counter: Values that only increase (e.g., total_http_requests)
- Gauge: Values that can go up and down (e.g., current_memory_usage)
- Histogram: Observations distributed into buckets (e.g., request_duration_seconds)
Custom Autoscaling
With metrics scraping enabled, you can now set up autoscaling based on your custom metrics instead of just CPU and memory usage.How to Configure Custom Autoscaling
- Navigate to your application dashboard
- Select your service
- Go to the “Resources” tab
- Configure basic autoscaling:
- Enable “Enable autoscaling (overrides instances)”
- Set “Min instances” (e.g., 1)
- Set “Max instances” (e.g., 10)
- Switch to custom metrics mode by clicking the customize icon
- Configure custom metrics:
- Metric Name: Select a metric from your exposed Prometheus metrics
- Query: Write or modify the PromQL query (defaults to
avg(<metric_name>)
) - Threshold: Set the threshold value that triggers scaling

Query Requirements for Autoscaling
When using custom metrics for autoscaling, your PromQL query must:- Return a single numeric value (scalar)
- Examples of valid queries:
avg(metric_name)
→ Returns a single average valuesum(rate(http_requests_total[5m]))
→ Returns a single sum valuemax(some_latency_metric)
→ Returns a single maximum value
- Vector results (multiple time series)
- String results
- No data/empty results
avg()
, sum()
, or max()
to reduce it to a single value.
Switching Between Autoscaling Modes
You can switch between:- Default Mode: Autoscale based on CPU/Memory usage
- Custom Mode: Autoscale based on your application metrics
Example Use Case: Data Processing Pipeline
Consider a data processing pipeline with two separate Porter applications:Analytics Ingestion API
A Flask/FastAPI service that ingests analytics events from multiple client applications and publishes them to RabbitMQ for processing. Metrics Configuration:Event Processing Service
A separate application with Celery workers that process events from RabbitMQ and stores them in your data warehouse. Custom Autoscaling Configuration:- Metric Name:
rabbitmq_queue_messages{queue_name="user_events"}
- Query:
sum(rabbitmq_queue_messages{queue_name="user_events"})
- Threshold:
1000
(scale up when more than 1000 events are waiting)