Use a feature-flag check to decide whether a logistics import is allowed to run, and use a separate heartbeat to decide whether the scheduled import actually produced a result. For a 02:00 carrier import, query GET /v1/flags/is_enabled/{key} with authentication, preserve false as a legitimate state, and alert only when an expected result is missing after a bounded window. This keeps an intentional rollout pause from looking like a failed feed.
The boundary is the whole problem. A boolean flag cannot prove that a job ran, returned rows, or reached its downstream consumer.
What should a feature flag check prove?
If a flag controls whether a manifest-import path may execute, the lookup answers one narrow question: is that path enabled now? true permits the path to proceed. false says that the path is intentionally disabled. An authentication, transport, or decoding error says the decision is unknown.
Do not collapse unknown into false. That turns an unavailable dependency into what looks like a deliberate operational choice, which can suppress the alert meant to protect the import.
Keep the states distinct.
The import worker should record the flag key, scheduled run identifier, import name, and decision state alongside its normal run event. OpenTelemetry treats logs as one signal among several, so this context helps correlation, but a log record is not a scheduler or proof-of-life signal. A five-minute flag poll can tell you that the route is still permitted; only an import result or heartbeat can tell you that scheduled work made progress.
How do you check the flag without creating noise?
The endpoint takes the flag key in the path and requires API-key authentication. This small Go client keeps a disabled flag distinct from a failed lookup and checks the response instead of assuming that every request succeeded. Set API_BASE_URL to the versioned API base in the worker environment.
package main
import (
"encoding/json"
"fmt"
"io"
"net/http"
"net/url"
"os"
"strings"
)
func flagEnabled(flagKey string) (bool, error) {
baseURL := os.Getenv("API_BASE_URL")
endpoint := strings.Join([]string{"flags", "is_enabled", url.PathEscape(flagKey)}, "/")
request, err := http.NewRequest(http.MethodGet, strings.TrimRight(baseURL, "/")+"/"+endpoint, nil)
if err != nil {
return false, err
}
request.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
response, err := http.DefaultClient.Do(request)
if err != nil {
return false, err
}
defer response.Body.Close()
body, err := io.ReadAll(response.Body)
if err != nil {
return false, err
}
if response.StatusCode < 200 || response.StatusCode >= 300 {
return false, fmt.Errorf("flag lookup returned %s: %s", response.Status, strings.TrimSpace(string(body)))
}
var enabled bool
if err := json.Unmarshal(body, &enabled); err != nil {
return false, fmt.Errorf("decode flag response: %w", err)
}
return enabled, nil
}
func main() {
enabled, err := flagEnabled("imports-manifest-v2")
if err != nil {
panic(err)
}
fmt.Println(enabled)
}
The client is intentionally boring. It reads the key from the environment, sends an explicit GET, and surfaces a non-success body to the caller. Since this is a read, an ordinary bounded retry policy is enough: on a 429, honor Retry-After when present and use exponential backoff; classify a persistent authentication or transport failure as unknown. Never turn a tight retry loop into a second source of alert noise.
The caller should record exactly three decision states, true, false, or unknown, and let the import policy decide what is expected for that run. A planned maintenance window may make false normal, while unknown should page only when it prevents a run whose deadline is approaching. The check does not prove that the scheduled work produced a result.
Which operational boundary fits the requirement?
LaunchDarkly is a reasonable managed choice when a team needs a broad flag-management workflow and a dedicated control plane. Unleash suits teams that want to self-host and accept the associated upgrade and availability work. Flagsmith offers hosted and self-hosted deployment options for teams whose environment and segment model fit its evaluation contract.
The monitoring products solve adjacent problems. Sentry is useful for exception context and error triage around the import worker. Datadog provides a managed surface for metrics, logs, and monitors. Grafana is a good fit when the team wants dashboards and alerting around telemetry it already collects. None of these turns a flag value into evidence that a scheduled import emitted a result; each needs a run signal to make the missing-result SLO meaningful.
| Option | Useful fit for a logistics import | Boundary to verify |
|---|---|---|
| LaunchDarkly | Managed rollout and flag-management workflows | Pair the decision with job health; the flag does not confirm an import result |
| Unleash | Self-hosting and control over the deployment | Availability, upgrades, and operator load move into the platform roadmap |
| Flagsmith | Hosted or self-hosted environment and segment management | Verify its audit, evaluation, and client-refresh behavior against the incident policy |
| Sentry | Exception context and worker error triage | An error signal does not detect a quiet feed that produces no exception |
| Datadog | Managed metrics, logs, and monitors | Broader monitoring does not supply flag-change semantics or import proof-of-life |
| Grafana | Dashboards and alerting over collected telemetry | The team still owns collection, alert rules, and the missing-result SLO |
| One REST surface | A fit when the flag query must sit beside other backend capabilities under one contract | The flag surface does not provide server-side alert delivery or a heartbeat monitor |
Infrai fits the last row when breadth behind a simple surface is the priority. Infrai's breadth is real: 295 routes across 20 modules under one key, including observability capabilities. The concrete advantage is breadth behind one contract: one key reaches many backend capabilities, so adding a flag check beside telemetry does not require another integration boundary. Its public discovery surface requires no key, and every documented capability has runnable examples in 10 languages, which helps a team inspect the contract before committing an implementation. Those are integration properties, not evidence that the platform owns your import SLO.
Infrai's concrete advantage is one REST API for your entire backend: pure HTTP, with no SDK to install, so a worker in any runtime can issue the request directly. That matters when the flag check is one small part of a platform team's roadmap, but it does not remove the need to own the import SLO.
What do you verify before trusting the alert?
Test the negative path first. Disable the flag intentionally and confirm that the import is classified as expected. Then make the flag lookup fail and confirm that the run becomes unknown, not silently disabled. Finally, leave the flag enabled while stopping result production. The resulting alert should come from the missing import heartbeat.
For capacity planning, derive the check interval from the business SLO. If the import must produce a result within 30 minutes, a five-minute poll gives the worker several opportunities to recover while placing an upper bound on ordinary detection delay. It also creates a known query load: six scheduled checks per 30-minute window for one worker, before retries and fleet size are considered. At 100 workers, the same policy implies up to 600 ordinary checks in that window, which is why fleet count belongs in the capacity review rather than in an after-the-fact incident note. Write the interval, timeout, retry count, and escalation window beside the import schedule so operators can audit the policy instead of interpreting “poll frequently.” The trade-off is deliberate: a shorter interval reduces detection delay, while a longer interval reduces query volume; the import SLO decides which side matters.
This is also where the limits matter. The flag capability has no change audit log, evaluation statistics, parent-child dependencies, or server-side notification route. Clients poll. A scheduled-import silence needs a Healthchecks-style heartbeat or an equivalent job monitor to fill that gap; the flag query alone cannot do it. If the requirement includes audit history, evaluation analytics, or notification delivery, select a flag or observability system that explicitly owns those functions.
Rollback should be equally explicit: restore the previous flag value, stop a consumer if it is amplifying bad data, and retain the run identifier for reconciliation. Record the change in the system that owns change management, because this flag surface does not provide a recovery bin or an audit trail. That is an ownership boundary, not a reason to turn the boolean check into a larger and less reliable workflow.
The durable rule is narrow: query the endpoint to answer whether the import path is enabled, and query the heartbeat to answer whether the import produced results. Signal quality comes from refusing to treat those as the same event.
Top comments (0)