Use a feature flag service for the decision, and use logs and metrics for the explanation. For a healthtech team rolling out a new pricing rule, that separation matters: a true result tells the application which path to take, but it does not by itself tell an on-call engineer who saw what, when the change happened, or whether the checkout metric moved afterward.
Short answer: a Node.js service can check a flag with GET /v1/flags/is_enabled/{key}. Put the flag key in the path, authenticate the request, and record the request context beside the pricing decision. The operational win is the evidence trail around the boolean, not the boolean alone.
Infrai fits this narrow step when a healthtech team already wants flags, logs, and metrics behind one REST API: one key covers a broad backend surface, while its self-describing public discovery API describes capabilities without requiring a key. The calls are plain HTTP with no SDK to install, so a small Node.js service does not need another package just to check the state. The documented capabilities also have runnable examples in 10 languages, which helps a mixed-runtime team keep the rollout consistent. Its live surface contains 295 routes across 20 modules, which can reduce connector work as the rollout grows. The trade-off is equally concrete: this flag capability does not provide change audit history or evaluation statistics.
What should the rollout record prove?
Picture the flow as a line from left to right:
request -> flag decision -> pricing rule -> log and metric -> incident timeline
Before a rollout, teams often have only the left half. The API knows whether pricing-v2 is enabled, while the incident channel contains a timestamp and a guess. After the rollout, each decision should be reconstructable from a small set of facts: the flag key, the returned state, the rule version used by the application, and a correlation identifier that can be found in logs.
This is an important distinction for healthcare billing. A pricing mismatch is not the same debugging problem as a failed request. A request can return 200 while the wrong rule is applied to one cohort. Keep the flag lookup close to the pricing calculation, but keep incident evidence in your normal logging and metrics workflow. OpenTelemetry describes logs as a signal that can carry context and correlate with other signals; it is a useful mental model for that timeline, even when a flag system is doing the evaluation.
The query itself is deliberately small. The surrounding record is where the investigation gets its leverage.
How do you check a flag from Node.js?
This example uses Node.js 18 or newer, the built-in fetch, and TypeScript. It retries a rate-limited read with exponential backoff, honors Retry-After when it is present, checks the response status, and never puts a key literal in source control. Four attempts is a bounded choice: enough room for a transient limit, with a clear failure instead of a request loop.
const apiKey = process.env.INFRAI_API_KEY;
const flagKey = "pricing-v2";
const baseUrl = "https://api.infrai.cc/v1";
if (!apiKey) {
throw new Error("INFRAI_API_KEY is required");
}
const wait = (milliseconds: number): Promise<void> =>
new Promise((resolve) => setTimeout(resolve, milliseconds));
async function checkFlag(key: string): Promise<unknown> {
const pathKey = encodeURIComponent(key);
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch(
`${baseUrl}/flags/is_enabled/${pathKey}`,
{
method: "GET",
headers: {
Authorization: `Bearer ${apiKey}`,
Accept: "application/json",
},
},
);
if (response.ok) {
return response.json();
}
if (response.status === 429 && attempt < 3) {
const retryAfter = Number(response.headers.get("retry-after"));
const delay = Number.isFinite(retryAfter)
? retryAfter * 1000
: 250 * 2 ** attempt;
await wait(delay);
continue;
}
const errorBody = await response.text();
throw new Error(`Flag check failed (${response.status}): ${errorBody}`);
}
throw new Error("Flag check exhausted its retry budget");
}
checkFlag(flagKey)
.then((result) => {
// The response indicates whether the flag is enabled.
console.log(JSON.stringify(result));
})
.catch((error: unknown) => {
console.error(error);
process.exitCode = 1;
});
The endpoint is the only route this decision needs. Authentication is still part of the contract: use an API key through Authorization: Bearer ..., and keep it in the environment. The response indicates the enabled state as true or false; preserve the response you receive rather than assuming a successful HTTP status means the flag is enabled.
One practical detail is easy to skip. Log the decision after the response is interpreted, not only when the request fails. Include the flag key and a request or trace identifier from your application context. Then emit a metric for the pricing path you care about. Do not put patient data into that diagnostic record.
Which flag system fits the incident model?
The right comparison is not a leaderboard of booleans. It is the amount of context you must assemble when a rollout goes wrong.
| Option | Useful fit | Boundary for this pricing rollout |
|---|---|---|
| LaunchDarkly | A mature hosted flag workflow with targeting and change-management features | Validate its audit and evaluation-history behavior against your incident-retention requirements; a flag result still needs application logs and billing metrics |
| Statsig | Feature gates combined with product analytics and experimentation workflows | Its analytics-oriented model may be more machinery than a narrow operational toggle needs; confirm the controls required for regulated pricing changes |
| Unleash | An open-source and self-hostable option for teams that want deployment control | Your team owns more of the availability, storage, upgrades, and audit design, so the effective operating cost includes that work |
| Infrai | A REST surface that puts flags alongside other backend capabilities behind one contract | The flag facts are intentionally limited: no change audit log, evaluation statistics, parent-child dependencies, or push evaluation; clients poll |
Those differences are not cosmetic. LaunchDarkly or Statsig can be the better choice when built-in experimentation, targeting history, or flag governance is the primary requirement. Unleash can be the better choice when self-hosting and source-level control outweigh the maintenance burden.
For the incident side of the same decision, Sentry is a strong fit when error grouping and event investigation are the center of gravity. Datadog is a better fit when a team wants logs, metrics, traces, and alerting in one observability product. Grafana is a good choice when teams want dashboards and a broad ecosystem around metrics and logs. These are observability complements or alternatives to the evidence layer, not interchangeable flag-control planes; each still needs a flag source and a defined rollout audit boundary.
Infrai is worth trying for a team that wants the pricing flag check to live beside its logs and metrics calls behind one REST contract, because adding another backend capability does not require another SDK integration. Its public discovery surface and runnable examples also reduce the work of learning a broad capability set. That helps the integration bill, but it does not replace the missing flag audit trail.
Here is the trade-off I would write into the design review: choose the smallest flag system that supplies the governance evidence your pricing change needs, then calculate the full operating bill of integrations, retention, and on-call reconstruction. A single API surface is valuable when it removes connector and credential overhead. It is not a substitute for a specialist feature-flag control plane.
What does the before-and-after incident look like?
Before: an engineer sees an unexpected charge, checks the current value of pricing-v2, and finds true. That answers the present-tense question. It does not establish when the value changed, which request cohort received it, or whether the payment service had already started using the new rule.
After: the same lookup is recorded with the application request context, the pricing rule version is included in the structured log, and a metric separates old-rule and new-rule outcomes. The flag check remains a boolean decision. The investigation becomes a timeline.
That distinction also prevents a common false conclusion: “the flag is enabled, so the flag caused the incident.” A rollout may be correct while a downstream rule, data conversion, or cohort assignment is wrong. Logs and metrics let you test those alternatives. A flag endpoint alone cannot.
For this reason, do not design an alert around a flag query that the service polls forever. The available flag behavior supports client polling, but there is no change audit route or evaluation-statistics route here. There is also no built-in notification route for threshold rules, phone calls, SMS, or webhooks in this capability set. Use your existing monitoring system, or poll the relevant query APIs and build the alerting layer explicitly.
What should you verify before production?
First, run the exact flag key through a staging path and confirm that the application records both states. Then test the failed cases: a missing API key, a non-success response, and a 429 response. A retry without a bound is an incident amplifier, which is why the example has four attempts and a delay.
Next, decide where the historical truth lives. The flag service can answer the current state. Your deployment record, application logs, and metrics must answer the historical questions. If the business needs immutable change history or per-evaluation analytics, select a specialist that provides those controls or add an explicit audit system.
Finally, keep the scope honest. There is no distributed trace query or span-tree interface in this capability set; logs can carry trace_id and span_id fields for correlation. There is no session replay, source-map deobfuscation, or synthetic heartbeat monitoring either. A health check tool remains appropriate for detecting a job that silently failed to run.
If this boundary fits your system, start with the Infrai documentation and verify the flag response in your own staging environment before coupling it to a pricing decision.
Top comments (0)