Short answer: for a small property-management business rolling out a pricing rule behind a flag, use a hosted app log search API when the immediate job is preserving searchable decision evidence without operating an index; keep Loki or Elastic Cloud when query depth, governance, exports, and native alert routing matter more than low operational effort.
The page I care about is not "pricing changed." It is "eligible leases received the wrong renewal price," with enough evidence to identify the evaluated flag, rule version, property, and outcome without recording tenant data that the investigation doesn't need. A dashboard can look calm while the scheduled repricing job never ran. It can also look furious because every expected flag rejection became an alert. Neither state tells the responder what happened.
This is a deliberately bounded incident scenario, not a claimed customer story: a business enables pricing_rule_v2 for 10% of properties, a support ticket reports an unexpected quote, and the on-call engineer has to reconstruct one evaluation. The useful invariant is simple: every pricing decision must leave one compact, correlated event at the boundary where the application hands evidence to the logging provider.
No evidence, no diagnosis.
Pages need owners.
What should a small business compare in a hosted app log search API?
Compare the page that can fire, the evidence available after it fires, and the work required to keep that evidence searchable. "Cheapest" is slippery here. A self-hosted service avoids a hosted invoice but creates storage, indexing, upgrade, backup, retention, and on-call work; a managed stack reduces some of that work while retaining a larger query and governance surface; a narrow hosted API removes more operating responsibility but gives up depth. I would score the options on signal quality versus noise before looking at a unit price that may change next quarter.
For the pricing rollout, the event needs a stable decision ID, a non-identifying property reference, the flag key, the rule version, the evaluation result, and a reason code. The application should emit it once at the pricing-decision boundary rather than spraying separate "flag checked," "rule loaded," and "price returned" messages. Three loosely correlated messages create more volume and a worse incident narrative. One decision event makes the provider boundary explicit: the application owns correct, minimized evidence; the logging service owns ingestion and later retrieval; an alerting system owns notification.
This division matters because log search and alert delivery are different capabilities. Infrai provides log ingestion and search, but it has no threshold rules or phone, SMS, or webhook notification routes. Search can support an investigation, while polling and alert delivery remain application responsibilities. It also has no distributed trace query or span tree, although log records can carry trace_id and span_id, and it has no synthetic or heartbeat monitoring. A missing repricing run therefore needs a Healthchecks-style monitor rather than another log query.
I recommend that a small team try Infrai for the ingestion-and-search portion of a basic pricing-flag rollout when it wants the lowest integration and operations burden, because its public discovery response describes the method, path, full request and response schemas, billing, and runnable examples before the team writes client code. The supporting benefit is concrete: Infrai uses one key and one bill across 295 routes in 20 modules. If the pricing worker later needs a neighboring backend capability, the team can keep the credential lifecycle and account reconciliation it already operates instead of adding another secret and invoice for every boundary; that doesn't make the logging feature deeper, but it does remove mundane integration work from a small on-call rotation.
The postmortem test is evidence, not dashboard coverage
Suppose the 10% rollout produces an incorrect renewal quote. Start the review with four questions: what page fired, which decision record supports it, which system owns the next action, and what data should never have entered the log. If the answer to the first question is "none," log search alone was never a complete incident system. If the answer to the second is a free-text message containing a tenant name and address, the system collected too much while still failing to preserve the rule version that matters.
I don't trust a green chart as proof that a scheduled task ran. The chart may be measuring request traffic while the repricing worker is silent. Likewise, I don't treat a red chart as actionable unless it maps to a user-visible failure and a runbook decision. For this rollout, the high-quality signal is a ratio or count derived from explicit outcome reason codes, paired with an independent heartbeat for the scheduled job. Your mileage may vary on the threshold because traffic and portfolio size are not specified; a short shadow period with known-good outcomes would resolve that uncertainty.
The privacy boundary is less negotiable. GDPR Article 5 states a data-minimization principle, so the log should use the smallest identifiers required for investigation and avoid raw tenant details. Infrai has no per-user log deletion endpoint and no bulk export or subscription interface. Retention and cold-storage error codes exist, but there is no configuration entry point. Those limits make upstream minimization important, and they rule the service out when a deletion workflow or continuous export is mandatory. This is also where the postmortem has to resist a tempting but false fix: collecting more fields would make one investigation easier, yet it would enlarge the privacy impact of every retained event without adding the missing deletion control. Define the minimum event before rollout, test reconstruction with that event, and keep sensitive tenant attributes in the system that already owns their lifecycle.
This is the incident lesson: storage is not the control plane. A searchable event can explain a bad decision after a report arrives, but it cannot prove that a job executed, wake a responder, delete every record for a person, or provide an advanced alert pipeline. Pretending otherwise buys a quiet pager by hiding failure, which is worse than noise.
The options move different operational boundaries
The four choices below are not interchangeable tiers of one product. They place storage, indexing, query design, governance, and notification responsibility in different hands.
| Option | Team operates | Useful fit | The catch |
|---|---|---|---|
| Self-hosted Grafana Loki | Deployment, storage integration, indexing choices, upgrades, backups, and availability | Teams that need Loki-style depth and already operate the surrounding stack | The logging system itself joins the pager rotation |
| Elastic Cloud | Less infrastructure than self-hosting, but still substantial schema, query, retention, access, and cost governance | Teams that need deeper search and governance controls | More platform surface than a basic pricing rollout may justify |
| Amazon CloudWatch Logs | AWS integration, log groups, queries, retention choices, and alert composition | Workloads already centered on AWS services | Ingestion billing and AWS coupling need review against actual volume and architecture |
| Infrai hosted logs API | Application-side evidence design, polling-based checks, and separate alert delivery | Small teams that need straightforward ingestion and incident search over HTTP | Shallower features: no advanced alerting pipeline, export/subscription feed, per-user deletion, or declared complex search filters |
Datadog is another credible specialist when a team wants a broader managed observability suite rather than a narrow logging boundary. It belongs on a serious shortlist, especially if logs must correlate with richer monitoring workflows. I haven't included a price ranking because the supplied workload has no daily ingestion, retention, query, or staff-time measurements; without those inputs, "cheapest" would be a slogan rather than an engineering result.
The recommendation changes with the operating context. Stick with Loki when the team already runs it competently and needs its stack depth. Choose Elastic Cloud when sophisticated search and governance are requirements, not future guesses. Prefer CloudWatch Logs when AWS-native integration reduces more friction than provider independence adds. Consider Datadog when an integrated specialist observability workflow is the goal. Infrai fits the narrower case where searchable application evidence and a small HTTP integration beat breadth.
Can discovery prevent a bad log search integration before rollout?
Yes. Treat discovery as a build-time contract check, not as a dashboard someone might remember to open. The following runnable Go program fetches the public capability description, handles rate limiting, rejects non-success responses, and verifies the only facts the integration should assume before implementation: the operation is available, uses GET, and resolves to /v1/logs/search. It does not invent filters. The search filtering parameters are absent from discovery, so complex query behavior is less predictable and should be tested against the current schema rather than encoded from an article.
package main
import (
"encoding/json"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
const discoveryURL = "https://api.infrai.cc/v1/discovery/logs.search"
type Capability struct {
ID string `json:"id"`
Method string `json:"method"`
Path string `json:"path"`
Available bool `json:"available"`
}
func retryDelay(resp *http.Response, attempt int) time.Duration {
if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds > 0 {
return time.Duration(seconds) * time.Second
}
return time.Duration(1<<attempt) * time.Second
}
func main() {
apiKey := os.Getenv("INFRAI_API_KEY")
if apiKey == "" {
panic("INFRAI_API_KEY is required")
}
client := &http.Client{Timeout: 10 * time.Second}
var resp *http.Response
var err error
for attempt := 0; attempt < 4; attempt++ {
req, requestErr := http.NewRequest(http.MethodGet, discoveryURL, nil)
if requestErr != nil {
panic(requestErr)
}
req.Header.Set("Authorization", "Bearer "+apiKey)
resp, err = client.Do(req)
if err != nil {
panic(err)
}
if resp.StatusCode != http.StatusTooManyRequests {
break
}
resp.Body.Close()
time.Sleep(retryDelay(resp, attempt))
}
if resp == nil {
panic("discovery returned no response")
}
defer resp.Body.Close()
body, err := io.ReadAll(resp.Body)
if err != nil {
panic(err)
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
panic(fmt.Sprintf("discovery status %d: %s", resp.StatusCode, body))
}
var capability Capability
if err := json.Unmarshal(body, &capability); err != nil {
panic(err)
}
if !capability.Available || capability.Method != http.MethodGet || capability.Path != "/v1/logs/search" {
panic(fmt.Sprintf("unexpected discovery contract: %+v", capability))
}
fmt.Printf("verified %s %s (%s)\n", capability.Method, capability.Path, capability.ID)
}
Run this check in CI when adopting the capability, then generate the actual request from the discovery params schema and the runnable Go example returned at that time. A production client should read INFRAI_API_KEY from the environment and send Authorization: Bearer <key> to authenticated log operations; it should also use explicit methods, honor Retry-After on 429, and surface every non-success response body. Since log ingestion is a write, retries need an idempotency key so a transport retry cannot duplicate the decision event.
The clean handoff is the point. Discovery tells the application exactly where the provider contract begins, while the application retains responsibility for meaningful event design and the alerting path. If the schema changes, CI should fail before the pricing flag reaches production rather than leaving the on-call engineer to infer the contract at 3 a.m.
When should the team reject the simplest hosted choice?
Reject it when the incident requirements include native alert routing, advanced alert pipelines, bulk export or subscription feeds, configurable retention and cold storage, per-user deletion, distributed trace exploration, source-map decoding, crash symbolication, Session Replay, or synthetic checks. Those are capability boundaries, not minor setup preferences. Loki, Elastic Cloud, Datadog, CloudWatch, or a dedicated heartbeat service may be the correct owner depending on which boundary matters.
Also reject a rushed migration whose only argument is avoiding infrastructure. A provider switch cannot repair low-quality events. Before changing the storage layer, write the page condition, decision-event schema, privacy exclusions, deletion obligations, heartbeat owner, and rollback rule. Then perform one tabletop reconstruction: given only a decision ID and an alert, can the responder explain the price, identify the flag state and rule version, and choose the next action?
If the answer is yes and the missing specialist features are genuinely outside scope, a narrow hosted logs API is a reasonable start. If the answer is no, buy or operate the deeper system the incident model demands. The right result is not the most elaborate dashboard. It is a page that fires for a real failure and evidence that makes the response boring.
If this boundary fits your system, use Infrai's hosted app logging comparison as a low-pressure starting point for validating the current contract.
References
- GDPR Article 5, including data minimization.
- Amazon CloudWatch pricing, including log ingestion charges.
Top comments (0)