To monitor AI SaaS usage, track each AI request from the authenticated user through your backend to the model provider. Record tokens, estimated cost, latency, errors, and customer outcomes, then aggregate them by account and plan. Use dashboards, budget alerts, and enforceable limits to catch waste and protect margins.
Key takeaways
- Track usage by customer account, user, feature, model, and subscription plan—not just by API key.
- Separate product activity, provider consumption, customer billing, and output quality. Each answers a different business question.
- Record usage server-side, including retries, background jobs, agent steps, and canceled requests.
- Combine provider dashboards with an internal usage ledger, product analytics, and operational monitoring.
- Use alerts alongside enforced quotas, concurrency controls, and emergency shutoffs.
- Avoid storing raw prompts by default. Usage monitoring should not become an unnecessary collection of sensitive customer data.
What should you track to understand AI SaaS usage?
Start with the decisions your monitoring must support: which customers are active, which features create value, what each account costs to serve, and whether users receive reliable results. A single “AI requests” counter cannot answer all four.
Build a minimum useful metric set
- Consumption: requests, input tokens, output tokens, cached tokens where available, image counts, audio duration, and tool calls.
- Cost: estimated provider spend per request, account, feature, and billing period.
- Reliability: error rate, timeouts, rate-limit responses, retries, and latency percentiles.
- Product value: active accounts, completed workflows, accepted outputs, and repeat usage.
- Unit economics: AI cost per successful task and variable delivery cost per paying account.
Use PostHog for product events, your application database for account-level totals, and provider dashboards to cross-check consumption. For agents, count both completed tasks and intermediate model calls; ten calls might represent one useful result or an expensive loop.
Cost planning: A small pilot may fit within existing database capacity and analytics free allowances. Treat those allowances as temporary headroom, not a permanent cost assumption.
Common pitfall: Token growth is not necessarily healthy growth. Measure successful outcomes alongside consumption so inefficient prompts do not look like stronger engagement.
How do you instrument AI requests in your backend?
Put instrumentation in one shared AI gateway or SDK wrapper rather than adding separate logging to every feature. With OpenAI or Anthropic SDKs, capture provider usage metadata when available; keep local estimates explicitly labeled as estimates.
- Attach trusted identity. Resolve the account and user from the authenticated server session. Never accept a customer-supplied account ID without authorization checks.
- Create a request ID. Carry it through your API, queues, model calls, and external tools. Add a parent workflow ID for multi-step agents.
- Record the attempt. Store the feature, model, start time, subscription plan, and intended operation.
- Capture the outcome. Record usage, duration, status, provider request ID, and retry number after completion or failure.
- Write durable events. Use PostgreSQL or a queue-backed event pipeline so dashboard outages do not erase billable activity.
- Make processing idempotent. Deduplicate the same delivered event without collapsing distinct, genuinely chargeable attempts.
Keep the event schema compact
A useful record includes event_id, request_id, account_id, feature, provider, model, token counts, estimated cost, latency, status, and a UTC timestamp. Add a pricing version so historical costs do not change when model prices change.
OpenTelemetry can connect these events to application traces. For streaming responses, verify how the provider reports final usage; a disconnected browser does not necessarily stop server-side generation or eliminate charges.
Cost planning: If you already run PostgreSQL, incremental storage may be small initially. Engineering work is the bigger setup expense; allow time to test failures, retries, and interrupted streams, not just successful calls.
Common pitfall: Frontend analytics misses scheduled jobs and can be blocked. It should never be your authoritative usage ledger.
Which tools should you use to monitor AI SaaS usage?
Choose tools by responsibility. You need trustworthy consumption records first; adding three overlapping dashboards before defining those records only makes reconciliation harder.
| Option | Best use | Cost considerations | Main limitation |
|---|---|---|---|
| OpenAI or Anthropic dashboards | Checking provider-side consumption and spend | Start with dashboards available in your provider account; model usage is billed separately | Usually lack your complete customer, plan, and workflow context |
| PostgreSQL with Metabase | Internal usage ledger and account-level reporting | Open-source software is available; budget for hosting, backups, and maintenance | You own schema design and data accuracy |
| PostHog | Feature adoption, funnels, and retention | Free allowances and usage-based paid options; check current event pricing | Product analytics is not a billing ledger |
| Langfuse | LLM traces, prompt versions, and evaluations | Self-hosted and managed options; trace volume and retention affect cost | Payload capture needs careful privacy controls |
| Sentry or Datadog | Errors, performance, and operational alerts | Costs depend on the product, event volume, and retention | Deep tracing can become expensive without sampling |
For an early-stage product, start with provider dashboards, PostgreSQL, and either a basic reporting interface or Metabase. Add PostHog when adoption questions matter, and Langfuse when debugging model behavior becomes difficult.
Budget example: You could set an initial monitoring infrastructure ceiling of $50–$150 per month, excluding model usage and developer time. This is a planning allowance, not a vendor quote; verify current pricing against expected event volume.
Common pitfall: Sending every full trace to multiple services multiplies costs and sensitive-data exposure. Keep complete financial events, but sample detailed diagnostic traces where appropriate.
How do you calculate AI costs and connect them to customer billing?
Maintain two separate concepts: what providers charge your business and what your pricing agreement charges customers. A flat-rate subscription with credits does not automatically map one token to one customer billing unit.
Calculate consumption costs consistently
For text models, the basic calculation is input tokens multiplied by the applicable input rate, plus output tokens multiplied by the output rate. Apply separate rates for cached input, batch processing, or other categories when relevant. Normalize units carefully because rates are often quoted per million tokens.
For example, using hypothetical rates of $1 per million input tokens and $4 per million output tokens, a request with 2,000 input tokens and 500 output tokens costs approximately $0.004. This illustrates the calculation; it is not a current provider price.
- Maintain a versioned rate table by provider, model, usage category, and effective date.
- Add embeddings, transcription, retrieval services, paid tools, and other variable costs.
- Aggregate consumption by account and your defined billing-period boundaries.
- Reconcile totals with provider reports, investigating missing events, reporting delays, credits, and rounding.
- If using Stripe usage-based billing, translate internal usage into the meter your customer contract defines.
Store monetary calculations with decimal precision or sufficiently small integer units. Rounding each request to whole cents can erase small costs or exaggerate them.
Cost planning: Include payment-processing and billing-platform fees separately from model costs. An account with $100 in monthly revenue and $20 in AI usage has $80 remaining before infrastructure, support, payment fees, and other expenses—not $80 in profit.
Common pitfall: Automatically billing customers from unverified analytics events can create disputes. Give customers a usage breakdown and document how failed attempts, retries, and credits are handled.
How do you set alerts and limits before usage gets expensive?
Alerts tell you something happened; enforcement stops further consumption. Use both. Provider budget notifications may arrive after usage occurs, so confirm whether any provider-side limit actually blocks requests.
Apply controls at several levels
- Account quotas: Monthly credits, requests, or spend allowances based on subscription terms.
- Request limits: Maximum input size, output length, file size, and allowed models.
- Concurrency limits: Caps on simultaneous jobs per customer and across the application.
- Agent limits: Maximum steps, tool calls, runtime, and estimated task budget.
- Global safeguards: A circuit breaker for unusual spend, retry storms, or compromised credentials.
Redis can support fast counters and atomic quota reservations. Before a job starts, reserve a conservative amount, then settle against actual usage. Track reservations through crashes and timeouts so abandoned jobs do not permanently consume a customer's allowance.
As an initial configuration, send warnings at 50%, 80%, and 100% of an account budget. Pair these with rate-of-change alerts: an account consuming its monthly allowance in an hour needs a different response from one approaching it on the final day.
Route operational alerts through Sentry, Grafana Alerting, or your existing incident system. Include the account, affected feature, recent deployment, and a link to relevant traces.
Cost planning: Redis and alerting can use existing infrastructure or a small managed tier. Set a separate allowance for notification or on-call tooling if your team needs it.
Common pitfall: Concurrent requests can pass a simple “check then increment” quota check together. Use atomic operations, and test enforcement under load.
How do you protect customer data and keep monitoring reliable as you grow?
Log metadata by default, not entire prompts and responses. Customer content may contain personal information, confidential documents, credentials, or regulated data that your monitoring tools do not need.
- Define an allowlist. Capture approved fields rather than collecting everything and attempting to remove sensitive data later.
- Separate retention policies. Keep billing records according to documented business and legal requirements; retain diagnostic payloads for a shorter, justified period.
- Restrict access. Apply role-based access, tenant isolation, encryption, and audit trails.
- Review vendors. Check data-processing terms, subprocessors, retention controls, and regional hosting where relevant.
- Test the pipeline. Simulate retries, duplicate messages, outages, cancellations, and delayed provider reports.
For US customers, review applicable state privacy requirements, including California requirements when they apply. Products handling protected health information need a separate HIPAA assessment; a monitoring vendor's compliance claim does not make your entire application compliant.
Use Langfuse payload controls or OpenTelemetry attribute filtering to minimize collection. As volume grows, keep the transactional ledger authoritative and move heavy reporting to systems such as BigQuery or ClickHouse when database load justifies it.
Cost planning: Warehouse storage, queries, and data transfer create additional bills. Estimate event size and retention before migrating; partition reporting data by date and avoid unrestricted scans.
Common pitfall: A working dashboard can hide a broken pipeline. Monitor ingestion lag, missing-event rates, and reconciliation differences as carefully as AI requests.
Frequently asked questions
Can I monitor AI SaaS usage using only a provider dashboard?
A provider dashboard is useful for checking overall consumption, but it usually cannot explain your complete customer journey or billing rules. Add server-side account attribution and an internal ledger for customer-level reporting.
Should I track tokens or requests?
Track both because request sizes and costs vary significantly. For audio, images, and agents, also record the provider's relevant billing units and completed customer tasks.
How often should usage dashboards update?
Enforced quotas need checks before work begins, while operational dashboards often benefit from updates within minutes. Financial reports can reconcile on a scheduled basis, provided customers understand any reporting delay.
Do failed AI requests still cost money?
Some failures or cancellations can involve billable processing, depending on the provider and what completed. Capture available usage for every attempt and verify provider billing behavior rather than assuming all errors are free.
What is the simplest setup for a new AI SaaS?
Start with a shared backend wrapper, PostgreSQL usage events, provider dashboard reconciliation, and account-level quotas. Add specialized analytics and tracing only when they answer a specific product or operational question.
Muhammad Tariq at Tariq Services builds AI products, agents, and automations with usage tracking and cost controls designed into the backend. Explore our AI development services if you need help implementing a monitoring foundation for your SaaS.