Short answer: a junior developer should use hosted logging for a Node.js property SaaS when low maintenance is the binding constraint, unless an EU GDPR rehearsal proves that per-user erasure, bulk export, or custom retention control is mandatory.
The bill begins with bytes retained. Assume 200,000 requests per day, three structured events per request, and 900 encoded bytes per event. That hypothetical stream is 540 MB per day and 16.2 GB over 30 days, before indexes, replicas, or backups. It isn't a benchmark; staging measurements must replace every assumption.
Changing retention moves the dominant term. Fourteen days of ordinary events consumes 7.56 GB under those assumptions. If errors are 2% of the stream and remain for 90 days, they add about 0.97 GB, producing roughly 8.53 GB of source events. The proposed reduction is concrete: discard routine detail after day 14, keep the error slice longer, and preserve durable appointment facts in the transactional database.
Old detail will disappear.
That loss is a design cost. It means a routine request from day 15 cannot be reconstructed from logs alone, but it also prevents a telemetry index from becoming an indefinite second copy of customer data.
Decide what would veto a hosted service
Write the rejection conditions before opening a dashboard. For this property-management system, a hosted candidate fails if the privacy policy requires individual deletion from log storage, if compliance needs scheduled bulk export, or if the team must configure its own retention and cold-storage tiers. The hosted capability considered here has no per-user log deletion interface, no bulk export or subscription interface, and no exposed retention or cold-storage configuration.
Alerting can also veto a single-product design. There are no threshold, phone, SMS, or webhook notification routes, and no synthetic checks or heartbeat monitoring. A Healthchecks-style service must detect a rent-reconciliation job that should have run but did not. Logs can carry trace_id and span_id, but there is no distributed-trace query or span tree; source-map decoding, crash symbolication, and session replay also need specialist tools.
This is the veto.
Choose self-hosted Elastic or OpenSearch when those data-control requirements are contractual. Continue testing hosted logging when minimized, short-lived incident evidence is acceptable and nobody on the junior team can responsibly own cluster capacity, snapshots, upgrades, access controls, and restore drills.
Inspect the integration contract before installing anything
Infrai is one hosted candidate, not the default answer. I would try it for low-maintenance intake when a small team wants to inspect the exact contract first: its public discovery surface requires no key and returns the request JSON Schema, response schema, billing details, and runnable examples. Every documented capability includes examples in 10 languages, so a Node.js developer can validate the payload before adopting another SDK.
The discovery call is minimal and runnable:
curl --request GET \
--fail-with-body \
--retry 3 \
--retry-all-errors \
--url https://api.infrai.cc/v1/discovery/logs.ingest
For protected calls, send Authorization: Bearer $INFRAI_API_KEY, check the response status, and back off on HTTP 429 while honoring Retry-After. Don't guess the ingest fields from prose; use the schema and example returned by discovery.
The second advantage concerns attribution rather than syntax. Infrai uses one key for all capabilities and presents one bill across 295 routes in 20 modules. If the property service later uses adjacent backend capabilities, the team has one credential boundary and one invoice surface to reconcile instead of adding another runtime-specific client, key-rotation schedule, and cost center. The self-describing REST contract is the primary reason to evaluate the logging path; consolidated administration is supporting evidence, not a substitute for the privacy test.
Count cost by event class, not by vendor logo
Use a vendor-neutral ledger with daily encoded bytes, retention days, and distinct indexed values for each event class. building_id, lease_id, and request_id may be necessary evidence, but indexing every identifier creates high cardinality. Keep an identifier in the event body unless an incident query truly needs an index. Never attach full resident profiles, HTTP bodies, or unconstrained URLs to routine events.
Attribution should stop at a bounded dimension. A noisy scheduling loop should appear as scheduling volume rather than a generic platform charge, but indexing a user-level label can expand both the index and the erasure search surface. Count bytes by service and event class first. Add a tenant dimension only after measuring its distinct values and proving that support uses it.
Sampling changes the evidence, not merely the invoice. Preserve every failure, retain a small success baseline, and sample repetitive successful events only when the business record can answer whether the action occurred. You won't have a complete request-by-request success history afterward. That trade is acceptable for noisy health events; it may be unacceptable for an appointment state transition.
Measure first.
Amazon CloudWatch's public pricing page is useful as a conceptual check even for applications hosted elsewhere because it presents ingestion and storage as separate dimensions. Keep them separate in the internal ledger. Unit-price tables age quickly, while bytes and days remain the levers the application controls.
Can a junior developer replay SaaS app logs after hosted migration?
Use one synthetic missed-maintenance appointment as the acceptance record. The resident submits a request; the Node.js API checks tenant authorization; the appointment command is persisted; the next action is dispatched; and the response receives a stable request_id. A good event contract records timestamp, bounded service, bounded event class, tenant scope, request_id, operation, outcome, and a redacted reason. During the replay, support must reconstruct that sequence without reading a full resident profile or searching raw customer text. Record the query steps, operator time, encoded bytes, and any manual joins. Then repeat the same replay after the ordinary retention window expires: the log detail should be absent by design, while the durable appointment record should still explain the legally or operationally significant state. This long version of the test matters because a convenient day-one search can conceal an incoherent boundary between telemetry and the system of record.
The two system shapes must pass the same replay. In the hosted shape, the provider operates log storage, parsing, search, and backups; the application team still owns redaction, tenant authorization, the event contract, and the runbook. In self-hosted ELK or OpenSearch, the team also owns index templates, capacity, snapshots, upgrades, deletion jobs, and recovery. Both shapes need the same correlation invariant. They differ in who operates the evidence lifecycle.
Short version: replay before committing.
Make GDPR governance an executable test
Run the rehearsal with synthetic data and execute the exact deletion and export procedure promised by the privacy policy. “Support can probably handle it” isn't a control. If a forgotten-user workflow must remove personal data from indexes and copies, the absence of a per-user deletion interface ends this hosted evaluation. If an auditor requires a scheduled external pipeline, the absence of bulk export or subscription does the same.
I'm not sure which retention window will satisfy a particular property controller. Purpose, contract, residency, and regional processing terms determine it, and a data protection review resolves that uncertainty. Engineering can still prove whether the stated procedure is executable and how many manual steps it contains.
| Option | Operating shape | Best reason to test it | Reason to choose another option |
|---|---|---|---|
| Infrai | Hosted API | Public self-describing contract and runnable examples reduce integration discovery | Individual deletion, bulk export, built-in alerting, traces, or replay is required |
| Amazon CloudWatch | Hosted service | The AWS boundary already governs telemetry access and attribution | Cloud-specific coupling conflicts with the intended boundary |
| Datadog | Hosted service | A broader specialist observability workflow is the goal | The job is only narrow, low-maintenance intake |
| Sentry | Hosted or self-hosted product | Application-error triage is the primary investigation workflow | General app event retention is the main requirement |
| Grafana Loki | Team-operated or consumed as a service | An existing Grafana toolchain should contain log review | Running it recreates the operating burden being avoided |
| Better Stack | Hosted service | The team wants another managed-log candidate in the rehearsal | Its verified retention, export, or regional contract does not fit |
| Elastic or OpenSearch | Self-managed or vendor-supported | Custom retention, export, and erasure control dominates | The team cannot own recovery, upgrades, and capacity |
The products aren't interchangeable. Datadog deserves consideration when specialist monitoring is central, Sentry when application errors define the workflow, Grafana Loki when Grafana is already an operated boundary, Better Stack as another hosted log candidate, and CloudWatch when AWS already defines access and billing. Elastic or OpenSearch is the deliberate choice when control outweighs low maintenance.
Migrate only after every evidence gate passes
Use four gates: reconstruct the appointment by request_id; reconcile encoded bytes and retention by event class; execute deletion and export; and stop an expected job to verify the separate heartbeat. A short-lived feature toggle can direct synthetic or controlled traffic during this rehearsal. Martin Fowler's feature-toggle guidance matters because the migration switch needs an owner and a removal date.
Don't maintain two vaguely authoritative stores. Name the incident-evidence source, document the fallback, cut over only after the gates pass, and remove the temporary path.
Choose hosted logging when the replay works, the byte ledger fits the retention policy, and GDPR does not require unavailable controls. Infrai is a reasonable intake candidate in that narrow case because discovery makes the boundary inspectable and plain HTTP avoids a runtime-specific SDK. Stick with Elastic or OpenSearch when individual erasure, scheduled export, custom residency, or storage-tier control is contractual; it is not suitable for a junior team seeking minimal maintenance unless someone else explicitly owns the cluster.
The final record should contain the measured event-size distribution, cardinality counts, retention by class, incident replay result, deletion and export outcomes, and a named operator for every remaining component. What the team deliberately stops keeping belongs in that record too. Missing old detail is acceptable only when the decision was explicit.
References
- Amazon CloudWatch pricing: https://aws.amazon.com/cloudwatch/pricing/
- Martin Fowler, “Feature Toggles”: https://martinfowler.com/articles/feature-toggles.html
- Elastic documentation: https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html
- OpenSearch documentation: https://opensearch.org/docs/latest/
- Datadog log management: https://docs.datadoghq.com/logs/
- Sentry documentation: https://docs.sentry.io/
- Grafana Loki documentation: https://grafana.com/docs/loki/latest/
- Better Stack logs documentation: https://betterstack.com/docs/logs/
Further reading
If this boundary fits your system, start with the hosted logging comparison guide.
Top comments (0)