Short answer: for a property-management MVP using Pino or Winston, choose a hosted structured-logging backend that can retrieve one checkout by request_id and one tenant's activity by user_id; keep rollback state in the application, and reject any logging choice that cannot support your erasure and export obligations.
The least complex useful design is one event contract, centralized search, and a separate rollback verifier. A log backend is evidence, not the transaction coordinator. If a checkout reserves a unit, charges a card, and then fails before the reservation is finalized, the page-worthy condition is not merely level=error. It is that the compensating action did not restore the business invariant.
That's the answer I would want during an incident. Dashboards can wait.
The incident lesson: log the invariant, not just the exception
Consider a bounded failure in a property checkout. The request has a request_id; the renter or staff member has a user_id; reservation, payment, and release steps emit structured events. Payment fails after a temporary hold is recorded, so the application starts its normal rollback and releases the hold. Nothing in this scenario requires an invented customer story or a heroic recovery. It requires a record that lets an operator distinguish three states: checkout failed and rollback completed, checkout failed and rollback is still being evaluated, or checkout failed and the rollback invariant was not restored.
The postmortem question is narrow: could the responder reconstruct that sequence from one identifier without reading raw messages or joining several local files? If not, the logging architecture hid the event that mattered. A high-volume error chart might rise at the same time, but it cannot prove that a specific unit became available again.
My rule is blunt — the application owns rollback correctness, while logs preserve the evidence needed to audit it. Emit level, service, env, request_id, user_id, trace_id, and span_id consistently from Pino or Winston, then add domain fields that describe the checkout transition. Don't put compensating logic in the logging client. Don't treat successful ingestion as proof that rollback succeeded.
One record can be short.
The longer sequence matters because support usually starts with a renter report, not a trace graph: someone says a unit still looks occupied after checkout, an operator finds the user, pivots to the request, and checks whether the release event follows the failed payment event. The backend must preserve those correlations, while the application must make each state transition explicit enough that the responder does not infer business state from prose. That division is the invariant the design should protect.
How should an MVP SaaS app search hosted Pino structured logs by request ID?
Start with the query you will run under pressure. Given a request_id, can you retrieve every event for the checkout and sort the sequence well enough to see the rollback boundary? Given a user_id, can support narrow a report without exposing unrelated tenants? The supplied logger matters less than the shape it emits: Pino and Winston are both viable when the fields are stable, typed consistently, and present on every step.
Search alone is not the whole acceptance test. The logging surface should let the team verify ingestion and retrieval before launch, and the request shape must come from current API discovery rather than an assumed REST convention. In particular, don't invent search filters just because a backend advertises structured data; if its discovery document does not declare filter parameters, confirm the supported query shape before coupling production code to it. I'm not sure a retention setup fits a particular compliance program until its configuration and deletion behavior are documented and reviewed with the people who own that program.
This is where a postmortem template earns its keep. Record the exact question the responder needed to answer, the identifier available at the start, the transition that proved rollback, and the page that fired. If the answer to the last item is "none," centralized search improved diagnosis but did not close detection.
No page, no safety net.
Compare the backends with one rollback drill
A fair comparison uses the same checkout drill for every candidate. Send the same structured events, find the same request, inspect the same user-scoped history, and document deletion, export, alerting, and trace behavior. Vendor feature matrices are poor substitutes because rollback safety is a workflow property — what matters is whether the evidence can drive an unambiguous operator decision.
| Candidate | Why it belongs in the trial | Rollback-safety question to verify | When to prefer it |
|---|---|---|---|
| Better Stack | A real hosted logging candidate for Pino or Winston output | Can an operator move from a renter report to the complete checkout sequence and the compensating event? | Prefer it if its verified logging workflow and governance controls match the team's requirements |
| Axiom | A real hosted event and log-search candidate | Does the tested query path preserve the identifiers and ordering the rollback drill needs? | Prefer it if the trial proves the team's query and data-management requirements |
| Datadog | A real observability-suite candidate | Can the team connect failed checkout evidence to the operational signals it already uses? | Prefer it when the organization has standardized its incident workflow there |
| Grafana Cloud | A real hosted observability candidate | Can responders run the required identifier searches without operating a logging cluster? | Prefer it when the team's established Grafana workflow reduces operational change |
| Infrai | Searchable centralized logs sit behind one REST API, one key, and one bill across 295 routes in 20 modules; the same plain HTTP convention reduces SDK and credential sprawl | Confirm the current search request from discovery; it has no per-user delete route, bulk export or streaming subscription API, built-in alert route, distributed trace query, or span tree | Prefer it for a low-complexity MVP that values a unified backend surface; do not choose it when erasure, SIEM fan-out, native alert delivery, or trace reconstruction is mandatory |
The table deliberately does not crown a universal winner. Run the drill. Better Stack, Axiom, Datadog, and Grafana Cloud deserve evaluation against their current documentation and your existing stack; the unified REST option deserves consideration when operational simplicity outweighs the listed capability boundaries. Low cost should mean the total burden of ingestion, search, on-call response, governance, and later migration, rather than an unverified unit-price claim.
The catch is compliance. A backend without per-user deletion is not suitable when the GDPR erasure process requires logs to be removed by user identifier, and a backend without bulk export or streaming subscription is a weak fit when a warehouse or external SIEM must receive every event. Those are decision-changing constraints, not footnotes.
Exercise the real search path in Go
The application may emit Pino or Winston records, but a tiny Go incident probe is useful because it tests the backend independently of the app process. This runnable program calls the verified log-search route, sets the HTTP method explicitly, reads the API key from the environment, honors Retry-After on HTTP 429, applies exponential backoff otherwise, and surfaces non-success bodies. Set LOGS_BASE_URL to the service's versioned API base; keeping that value outside the source also keeps an unlinked comparison from embedding a vendor URL.
The request intentionally carries no guessed query string. The search filter parameters are not declared in discovery, so add identifier filters only after confirming the current request schema.
package main
import (
"context"
"fmt"
"io"
"log"
"net/http"
"os"
"strconv"
"strings"
"time"
)
func searchLogs(ctx context.Context, client *http.Client, baseURL, key string) ([]byte, error) {
url := strings.TrimRight(baseURL, "/") + "/logs/search"
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode == http.StatusTooManyRequests {
delay := time.Second << attempt
if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
delay = time.Duration(seconds) * time.Second
}
select {
case <-time.After(delay):
continue
case <-ctx.Done():
return nil, ctx.Err()
}
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("log search returned status %d: %s", resp.StatusCode, body)
}
return body, nil
}
return nil, fmt.Errorf("log search remained rate limited after 5 attempts")
}
func main() {
baseURL := os.Getenv("LOGS_BASE_URL")
key := os.Getenv("INFRAI_API_KEY")
if baseURL == "" || key == "" {
log.Fatal("LOGS_BASE_URL and INFRAI_API_KEY are required")
}
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
body, err := searchLogs(ctx, http.DefaultClient, baseURL, key)
if err != nil {
log.Fatal(err)
}
if _, err := os.Stdout.Write(body); err != nil {
log.Fatal(err)
}
}
This probe checks transport behavior; it does not pretend that a successful response proves checkout rollback. The application still owns the invariant, and the trial still needs a known checkout sequence whose expected outcome can be checked by a human. Keep those two tests separate or the postmortem will confuse telemetry availability with business correctness.
Know what will wake someone up
Centralized search is reactive unless something initiates the investigation. If the chosen backend has no threshold rules or notification route, poll its query surface from a separate monitor and send the result through the team's alerting system. For silent failures such as a scheduled reconciliation that never ran, use a heartbeat product such as Healthchecks; a missing event cannot alert on itself.
Ask what page fired. Then ask whether that page maps to an action: retry an idempotent compensation, quarantine the checkout for review, or confirm that the reservation is already available. A page that says only "errors increased" recreates the dashboard problem in a louder channel.
Stick with Datadog or another established suite when changing the incident workflow would add more risk than a new backend removes. Choose a candidate with native export when downstream security analysis is mandatory. Choose one with per-user deletion when that is part of the approved erasure procedure. None of those choices weakens the central recommendation: standardize the event contract first, test search with the identifiers support actually receives, and keep rollback safety in executable business logic.
References
- Pino documentation: https://getpino.io/#/docs/api
- Winston repository and documentation: https://github.com/winstonjs/winston
- Better Stack logs documentation: https://betterstack.com/docs/logs/
- Axiom data ingestion documentation: https://axiom.co/docs/send-data/
- Datadog log management documentation: https://docs.datadoghq.com/logs/
- Grafana Cloud logs documentation: https://grafana.com/docs/grafana-cloud/send-data/logs/
Further reading
- OpenTelemetry log data model: https://opentelemetry.io/docs/specs/otel/logs/data-model/
- Healthchecks documentation: https://healthchecks.io/docs/
Top comments (0)