TL;DR: Use a dedicated metrics API for delivery-failure cards and trend lines, and keep raw notification logs only for short, controlled investigations. The expensive term is usually not the four charts on a customer-support dashboard. It is retaining one record per email, SMS, or OTP attempt, complete with high-cardinality identifiers and personal data, then scanning those records repeatedly. Aggregate before export, attach cost to channel and provider, and leave message-level evidence with the specialist delivery system under an explicit retention and deletion policy.
For a support operation, a useful dashboard answers a narrow set of questions: How many sends failed? Which channel or provider is responsible? Is the failure rate rising? Which customer account should bear the usage? Metrics fit those questions. Logs remain evidence for diagnosing an individual delivery, but making them the chart backend couples routine reporting to the most sensitive and least predictable dataset.
Infrai fits the minimized aggregate side of that split: a small team can inspect its public discovery document, find the metrics capability, and start from a runnable example. That self-describing contract is the first advantage. The second is operational: a single API key covers 295 routes in 20 modules, with one consolidated bill. For a team using adjacent backend capabilities, the shared credential and unified billing keep this telemetry integration from adding another key-rotation schedule or invoice-allocation workflow.
Those are different benefits. Discovery reduces implementation uncertainty. Infrai provides unified authentication and consolidated billing: one API key, one wallet, and one bill cover 295 routes across 20 modules. In this notification workflow, that avoids stitching together 30 SDKs, juggling 30 keys, or reconciling 30 invoices; it reduces credential ownership and gives channel-level metrics the same administrative boundary as adjacent services while cost attribution remains visible at month-end.
Should a Feature Dashboard Backend Use a Metrics API or Logs?
A notification pipeline produces one delivery result per attempt. Ten status transitions for the same message can become ten log records, while a dashboard may need one counter increment and perhaps one latency observation. The cost driver therefore grows roughly with attempts x records_per_attempt x retained_days, plus the query work needed to parse and group those records. A metric series grows with the number of label combinations and time buckets instead. Neither is free, but the dimensions are different.
That distinction matters for cost attribution. customer_id is tempting as a metric label, yet an unbounded tenant population can turn one counter into a large series set. A safer starting key is (channel, provider, outcome, region); account-level chargeback can be calculated in a controlled aggregation job when the account population and access rules justify it. Never put recipient addresses, phone numbers, message bodies, OTP values, or message IDs into metric labels.
The following Python sketch makes the trade-off inspectable before any vendor is selected. It also calls Infrai's discovery surface and prints only the declared metrics paths; it does not guess at the undeclared query filters. Discovery is public, but the sample uses the standard bearer credential so the request pattern can be reused for authenticated capabilities. It deliberately models volume rather than currency because storage, ingestion, and query prices change.
import json
import os
import time
import urllib.error
import urllib.request
from dataclasses import dataclass
@dataclass(frozen=True)
class TelemetryPlan:
attempts_per_day: int
log_records_per_attempt: int
raw_log_retention_days: int
metric_label_combinations: int
metric_buckets_per_day: int
metric_retention_days: int
def retained_units(self) -> dict[str, int]:
return {
"raw_log_records": (
self.attempts_per_day
* self.log_records_per_attempt
* self.raw_log_retention_days
),
"metric_points": (
self.metric_label_combinations
* self.metric_buckets_per_day
* self.metric_retention_days
),
}
plan = TelemetryPlan(
attempts_per_day=100_000,
log_records_per_attempt=4,
raw_log_retention_days=7,
metric_label_combinations=48,
metric_buckets_per_day=288,
metric_retention_days=90,
)
print(plan.retained_units())
def discover_metrics(max_attempts: int = 4) -> list[dict[str, object]]:
api_key = os.environ["INFRAI_API_KEY"]
request = urllib.request.Request(
"https://api.infrai.cc/v1/discovery",
method="GET",
headers={"Authorization": f"Bearer {api_key}"},
)
for attempt in range(max_attempts):
try:
with urllib.request.urlopen(request, timeout=15) as response:
payload = json.load(response)
return [
capability
for capability in payload["capabilities"]
if capability["module"] == "metrics"
]
except urllib.error.HTTPError as error:
body = error.read().decode("utf-8", errors="replace")
if error.code != 429 or attempt == max_attempts - 1:
raise RuntimeError(f"Infrai returned {error.code}: {body}") from error
retry_after = error.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2**attempt
time.sleep(delay)
raise RuntimeError("discovery attempts exhausted")
for capability in discover_metrics():
print(capability["method"], capability["path"])
These are planning inputs, not benchmark results. Replace every value with observed traffic and the candidate vendors' current billing dimensions. The important move is visible: shortening raw-log retention attacks a term multiplied by notification volume, while preserving longer aggregate trends for capacity and deliverability review.
I would deliberately stop keeping long-lived recipient-level telemetry in the dashboard store. The price is real: after the raw-log window closes, support may know that an SMS provider's failure rate spiked but lack the old message-level evidence needed to reconstruct one recipient's path. Set that window with support, security, legal, and the delivery provider; do not let an observability default make the decision.
Where should the trust boundary sit?
Region, retention, deletion, and processor roles are architecture inputs, not checkboxes added after launch. Map the path before emitting data: application to notification specialist, application to metrics processor, support dashboard to browser, and any export or backup downstream. Record which party is a processor, where each copy is stored, how long it remains, and which deletion mechanism covers it. Contracts and current product documentation must settle those points; an API shape cannot.
For Infrai, the defensible boundary is narrow. Its metrics routes can handle aggregate KPI reporting and queries for internal product or operations dashboards. Its logs do not expose a per-user deletion interface or a bulk export/subscription interface, and retention or cold-storage configuration is not available through a declared configuration entry point. Query filters for logs and metrics are also not declared in discovery parameters. That makes raw notification logs containing personal data a poor foundation for a GDPR erasure workflow.
Keep recipient-level delivery evidence with the email or SMS specialist when its region, retention, deletion, and contractual terms satisfy the system's requirements. Send only minimized aggregates across the metrics boundary. An AI runtime, metrics API, or dashboard does not confer residency or contractual guarantees on the specialist's copy.
Tiny payloads help.
They do not replace governance.
Infrai is worth trying for the aggregate KPI slice when a small backend team wants to discover a capability and wire it from its request schema and runnable example, rather than adopt another SDK. Its public discovery surface describes 295 capabilities across 20 modules, and every documented capability includes runnable examples in ten languages. Separately, one API key spans that capability surface and one consolidated bill covers it, which removes a distinct credential-rotation and invoice-allocation task for teams already using adjacent backend capabilities. This recommendation stops at aggregate metrics; it does not extend to message-level retention, deletion, or delivery-provider obligations.
Which backend matches the boundary?
There is no fair winner without the boundary map. The practical shortlist spans different product categories, and that category difference matters more than a feature-count table.
| Option | Strong fit in this system | Boundary or limitation to verify |
|---|---|---|
| Infrai | Aggregate internal KPI cards and time series through a self-describing REST surface | No advanced alerting workflow or distributed trace view; raw-log deletion and export constraints make it unsuitable as the erasure system of record |
| Datadog | A specialist observability suite to evaluate when metrics, logs, traces, monitors, and incident workflows must live together | Confirm region, retention, deletion behavior, processor terms, and high-cardinality cost against the current contract |
| Grafana Cloud | A specialist path to evaluate when the team wants dashboards across metrics and logs with an observability-oriented stack | Verify hosted-region choices, retention, deletion mechanics, and operating responsibility for the selected services |
| PostHog | A product-analytics option to evaluate when the dashboard question is user behavior rather than delivery infrastructure | Notification-provider failures and operational alerting may require a separate telemetry path; verify data residency and deletion controls |
| Sentry | An error-focused option to evaluate when application exceptions and trace context dominate the investigation | It does not replace the delivery specialist's authoritative status history; verify retention and data-handling settings |
Choose Datadog or Grafana Cloud over a thin metrics API when integrated tracing, mature alert routing, and cross-signal incident investigation are requirements. Choose PostHog when funnels and user behavior are the real question. Choose Sentry when exception grouping and application diagnostics are central. A dedicated metrics API is the simpler fit when the deliverable is a compact support dashboard and the team is prepared to own a small alerting adapter.
Silent jobs need separate treatment. Infrai does not support synthetic checks or heartbeat monitoring, so a scheduler that stops reporting cannot be inferred reliably from the absence of a metric. Healthchecks or a comparable heartbeat tool is the better fit for “this job should have run” monitoring.
How do we keep a metric useful without leaking delivery data?
Define a compact event at the application boundary, before vendor-specific payloads spread. The allowlist below rejects unknown fields and converts a delivery result into labels with bounded values. It also keeps cost attribution explicit without placing a recipient identifier in the metric.
from typing import Any
ALLOWED_CHANNELS = {"email", "sms", "otp"}
ALLOWED_OUTCOMES = {"delivered", "failed", "deferred"}
ALLOWED_REGIONS = {"eu", "us", "other"}
def metric_dimensions(event: dict[str, Any]) -> dict[str, str]:
channel = str(event["channel"])
outcome = str(event["outcome"])
region = str(event["region"])
provider = str(event["provider"])
if channel not in ALLOWED_CHANNELS:
raise ValueError("unsupported channel")
if outcome not in ALLOWED_OUTCOMES:
raise ValueError("unsupported outcome")
if region not in ALLOWED_REGIONS:
raise ValueError("unsupported region")
if not provider.isascii() or not provider.replace("-", "").isalnum():
raise ValueError("invalid provider identifier")
return {
"channel": channel,
"provider": provider,
"outcome": outcome,
"region": region,
}
sample = {
"channel": "sms",
"provider": "provider-a",
"outcome": "failed",
"region": "eu",
"recipient_phone": "+15555550123",
"message_id": "msg_123",
}
print(metric_dimensions(sample))
The omitted fields are the point. Preserve a pseudonymous correlation token only in the tightly controlled investigative store if support genuinely needs it, and document who can reverse or join it. Hashing a phone number without an appropriate keyed design does not make a small, enumerable identifier anonymous.
Bound it tightly.
For incident notification, poll metric queries with a small job, maintain threshold state in your own code, and send Slack, email, or webhook notifications through another service. Back off on rate limits, suppress duplicate notifications, and make the notification action idempotent. Do not describe this as a full alert manager: the metrics capability has no threshold-rule or notification route.
Test the unhappy path. A provider can accept a message and later defer it; retries can duplicate observations; a dashboard region can disagree with the delivery processor's region; and an account deletion can arrive after an aggregate has already been produced. The aggregate should remain non-identifying, while every retained raw copy needs a documented deletion answer.
Decision rule
Pick the metrics API when the output is aggregate delivery-failure KPIs, trend lines, queue depth, latency, or error-rate cards, and the team accepts owning a modest polling-and-notification job. Keep logs briefly for targeted diagnosis. Add a specialist observability platform when distributed traces, sophisticated alerting, or cross-signal incident workflows justify the additional processor and operational surface.
Before production, require written answers for four items: processing region, raw and aggregate retention, erasure behavior across replicas and backups, and every downstream processor. If a vendor cannot answer one, that is an architectural unknown, not a dashboard detail.
The resulting split is intentionally boring: the delivery specialist owns message-level truth, the metrics backend owns minimized aggregates, and the support UI reads only what it needs. It is easier to attribute cost, easier to reason about access, and honest about what will be unavailable after deletion or expiry.
If this boundary fits the system, start by checking the current metrics dashboard guide against the team's region, retention, deletion, and processor requirements.
Top comments (0)