See which parts of your Rails app really drive cost
ActiveUsage plugs into
ActiveSupport::Notifications
and turns runtime signals into practical cost estimates for
endpoints, jobs, and tasks, so your team can spot expensive
paths, prioritize optimizations, and explain where infra spend
comes from.
Local-first by design with a natural path to hosted analytics
$4.82
Today's cost
↑ 23%
vs last week
18
Endpoints
Cost by Endpoint — Today
Sort: highest ↓OrdersController#create
234 ms avg · 3.2k req
UsersController#index
98 ms avg · 8.1k req
ReportsController#show
145 ms avg · 1.4k req
ProductsController#show
22 ms avg · 12k req
SessionsController#new
8 ms avg · 900 req
OrdersController#create cost spiked 2.4× today vs baseline
Your app emits performance data, but not cost decisions
Teams can see latency, errors, and cloud invoices, but still struggle to answer which endpoint, job, feature, or customer is actually driving spend.
Billing is too far from the code
Your AWS bill shows totals. Your app shows requests and jobs. What is missing is the bridge between them, so the expensive code paths stay hidden.
APM answers a different question
Performance tools tell you what is slow. They do not tell you what is expensive at your real traffic volume or which workloads deserve budget attention first.
Teams need useful estimates, not fake precision
In shared environments you cannot measure the physical cost of a single request perfectly. You can, however, allocate infra cost well enough to make better engineering decisions.
Built for cost observability, not generic monitoring
ActiveUsage helps Rails teams connect runtime behavior to infrastructure spend without bolting on a heavyweight platform.
Local-first setup
Start with a gem and Rails Engine that run inside your app.
ActiveUsage plugs directly into
ActiveSupport::Notifications
so you can get value fast without sending data anywhere on day
one.
Cost allocation by workload
See estimated cost per
controller#action, background job, or task using a cost allocation model built
from runtime signals.
Cost Spike Alerts
When you move to hosted, get alerted when an endpoint or job jumps above its baseline before a deploy quietly increases your spend.
Historical Trends
Follow how estimated cost changes across deploys, traffic spikes, and product work so you can see what actually moved the bill.
Custom Tagging
Attribute cost by team, feature, tenant, or customer to make ownership clearer and support smarter chargeback conversations.
CI/CD Budget Gates
Add guardrails in CI when you are ready, so cost regressions get caught before they become production surprises.
Start locally, grow into hosted
The first step is intentionally small: install the gem, mount the engine, and start seeing cost estimates inside your app.
Install the gem
# Gemfile
gem 'activeusage'
$ bundle installMount the engine
# config/routes.rb
mount ActiveUsage::Engine,
at: '/activeusage'Configure the gem
# config/initializers/activeusage.rb
ActiveUsage.configure do |config|
config.app_name = "my-rails-app"
config.default_tags = {
environment: Rails.env
}
endThe first version lives inside your app. Later, you can add hosted history, alerts, exports, and team workflows without changing the core instrumentation model.
Simple, transparent pricing
Free for local visibility. Upgrade when you want history, alerts, and collaboration.
Starter
Local-first for one app and a fast path to first insight.
- ✓ 1 application
- ✓ Local dashboard
- ✓ Endpoint, job, and task estimates
- ✓ Short retention
- ✗ Hosted history
- ✗ Alerts & team features
Pro
Hosted analytics for teams that want history, alerts, and cross-app visibility.
- ✓ Up to 5 applications
- ✓ Hosted history and trends
- ✓ Alerts and notifications
- ✓ Export and integrations
- ✓ Multi-app views
- ✓ Custom tagging and team workflows
Enterprise
For organizations with advanced security, compliance, and scale requirements.
- ✓ Unlimited applications
- ✓ Advanced retention
- ✓ SSO / SAML
- ✓ Compliance and export controls
- ✓ Custom SLAs
- ✓ Dedicated support
A clearer way to talk about Rails cost
"For the first time we could point to a few expensive endpoints and say: this is where the bill comes from, this is what we fix next."
"What clicked for us was the model: not fake precision, but a useful allocation of cost that made prioritization much easier."
"The local dashboard made adoption easy. We did not need to buy into a full platform just to see whether the idea was useful."
Start with local cost visibility, expand when you need more
Install the gem, find the most expensive paths in your app, and add hosted workflows later if your team needs alerts, history, or exports.