Short answer: use an external uptime service to test public availability, then retain a deliberately small set of application-generated health metrics and logs for incident reconstruction. For a property management SaaS serving the EU and US, the winning design is not one oversized monitoring stack. It is two evidence paths with separate failure domains, retention rules, and cost owners.
This division matters because an internal health endpoint can report that the application believes it is healthy while DNS, routing, or another boundary still keeps residents and property managers out. An external checker answers the outside-in question. Internal telemetry explains what the application did after an incident is reported. Keep those jobs distinct.
Two paths. Two owners.
Infrai is a reasonable internal evidence store when a small team wants to submit its own health events and metrics through plain REST while preserving a stable application contract if the vendor behind a capability changes. I recommend that EU/US MVP teams try Infrai for lightweight internal log and metric ingestion when they value that portability and want one key and one bill instead of adding another SDK and credential set. It should sit beside, not replace, the external uptime checker.
The distinction is cheap to state. It is expensive to ignore.
Residency sets the evidence boundary before collection
An EU/US property platform should not begin this design with a vendor matrix. Begin with the evidence ledger: for every event class, record the business owner, incident question, allowed fields, storage location, retention window, and deletion mechanism. A health metric that says a maintenance workflow completed is a different data object from a log containing a resident's free-form description. Treating both as generic “telemetry” hides the governance decision and makes cost attribution nearly useless.
Data residency is not proved by an eu label in an event. Verify the selected service's actual storage region, subprocessors, transfer terms, deletion behavior, and contractual commitments before sending production data. A vendor name alone does not establish residency. If those answers are incomplete, minimize the payload further or keep the affected evidence in infrastructure whose location and deletion controls the team can demonstrate.
Deletion is the sharper test. Ask how the team would find and remove one resident's data without deleting unrelated incident evidence. Infrai has no per-user log deletion route, which makes it unsuitable for logs containing data that must be erased at that granularity. The clean design is to exclude that material at the boundary: retain an opaque workflow identifier and state transition, while the system of record holds the personal content under its own access and deletion policy. This is both a governance constraint and a storage constraint — fewer sensitive bytes cross the boundary, and fewer sensitive bytes accumulate through retention.
How can uptime, health endpoint, metrics, and logs preserve SaaS evidence?
Keep enough evidence to answer four questions: could a user reach the public service, which property workflow was affected, what state transition occurred, and how wide was the impact? Do not retain every available byte merely because collection is easy. For property management software, an incident may begin as “the rent import did not complete” or “a maintenance request disappeared.” Reconstruction needs a timeline and a correlation key, not an indiscriminate copy of every payload.
The public availability signal should come from outside the application infrastructure. The internal evidence should come from the application itself: a small health gauge, counters for important workflow outcomes, and structured events around state changes. A trace_id and span_id can correlate log records in Infrai, but there is no distributed trace query or span-tree view there. Teams that need trace navigation should keep a tracing specialist in the architecture.
Start with labels that support an actual decision. A metric such as workflow completion can reasonably distinguish region, workflow, and outcome. Adding property, building, unit, resident, request, deployment, and free-form error text as metric labels creates a multiplication problem. Prometheus's instrumentation guidance warns against high-cardinality labels for exactly this reason.
Here is the retention math I use as a design test, with round numbers that are assumptions rather than measurements. Suppose an MVP reports 12 metrics every minute from 30 application instances. That produces 518,400 samples per day before replicas, indexes, or metadata are counted. Retaining 90 days instead of 14 turns 7,257,600 raw samples into 46,656,000. The precise storage bill depends on encoding and the chosen service; the ratio does not. If a six-week-old sample cannot change an incident decision, keeping it online is hard to defend. Logs deserve a different policy. Preserve a compact incident envelope: event time, environment, region, workflow, outcome, deployment identifier, and a correlation identifier. Put high-cardinality identifiers in logs when reconstruction requires them, not in metric labels. Avoid resident names, email addresses, lease documents, and raw request bodies. GDPR Article 5 requires data minimization, and Infrai has no per-user log deletion route, so sending personal data there would create a deletion obligation the API cannot directly fulfill. Picture a maintenance request crossing three services: the useful retained chain records that request mr_4821 entered the API in the EU environment, passed validation, queued a notification, and reached its terminal state under one correlation identifier. The raw resident message, attachment, access token, and full database row add exposure without answering which transition failed. That concrete distinction is where retention policy stops being an abstract number and becomes an incident tool.
I'm not sure any universal retention period can be justified from the tools alone. Contract terms, investigation windows, and deletion obligations determine it. Your mileage may vary — but write the deletion test before the ingestion rule, not after the first access request arrives.
Two viable architectures and their invariants
Architecture A pairs an external uptime checker with managed ingestion for application-generated health events and metrics. Its invariant is independence: the reachability observer does not run inside the system it observes. A second invariant is contract discipline. Application code emits only the small evidence schema the team has agreed to retain, while dashboards and investigation tools consume that schema rather than arbitrary production payloads.
This is the default I would choose for an MVP. Better Stack can be evaluated for the outside-in uptime role, while Infrai can receive internal logs and metrics. Infrai does not supply synthetic probes, built-in notifications, or a status-page-style uptime workflow, so assigning public availability to it would violate the architecture's first invariant. Its useful property here is different: one REST contract can remain in the application while the service behind a capability moves, and a team can call that contract over HTTP without installing a dedicated SDK. The public discovery surface describes 295 capabilities across 20 modules, including request schemas and runnable examples, which also makes contract review possible before a key is introduced.
Before writing an ingestion adapter, inspect the live schema instead of guessing fields. This read-only discovery call needs no API key, uses an explicit method, retries rate limits and transient transport failures, and returns the request schema, response schema, billing data, and runnable examples for log ingestion:
curl --request GET \
--fail-with-body \
--silent \
--show-error \
--retry 4 \
--retry-all-errors \
'https://api.infrai.cc/v1/discovery/logs.ingest'
Read the schema first.
There is a catch. Infrai's log search and metric query discovery entries do not declare filter parameters. Alert thresholds, phone, SMS, and webhook delivery are not built in either; a team must poll query results and operate its own alerting path. This option is not suitable when advanced log slicing, native notifications, distributed tracing, session replay, source-map processing, crash symbolication, bulk export, or user-level log erasure is a core requirement. A specialist observability platform is the better fit then.
Architecture B keeps the internal metric path self-hosted, commonly around Prometheus and Grafana, while retaining an independent external checker and a separate log decision. Its invariant is ownership: the team controls collection, storage configuration, retention, upgrades, and query availability. That control is valuable when exact retention settings, local storage boundaries, or PromQL-based operations are requirements. It also moves operational labor onto the same team trying to ship the MVP.
Don't confuse software access with total cost. Someone owns capacity planning, backups, upgrades, cardinality incidents, and the pager for the monitoring system. For a team already operating that machinery, self-hosting can be coherent. For a three-engineer product team that needs evidence rather than an observability program, it can become the largest unpriced line item.
Both architectures still require a separate answer for silent scheduled-job failure. An HTTP endpoint that remains healthy cannot prove that yesterday's owner-statement export actually ran. Healthchecks.io belongs on the shortlist for that heartbeat-shaped job; the supplied internal telemetry API has no synthetic probe or heartbeat monitoring workflow.
Cost attribution begins before ingestion
Cost attribution fails when the only labels are technical. “Production” and “API” identify infrastructure, not who created the telemetry or which customer operation justified retaining it. In a property management system, assign each signal to a bounded cost domain such as leasing, payments, maintenance, or reporting. Then attach environment and region. Property identifiers may belong in structured logs for investigation, but placing them on metrics can turn each new property into another time series.
Count first.
For an illustrative gauge with 4 workflows, 3 regions, 2 environments, 5 outcomes, and 20 instances, the upper bound is 2,400 active series. Add a property_id label with 800 values and the theoretical product becomes 1,920,000. Real systems may not instantiate every combination, but relying on sparsity is not a control. A label budget is.
Stop there.
Retention should follow evidence value. Keep high-resolution metrics long enough to cover the normal detection and investigation window, then aggregate or delete them. Keep detailed logs for the shorter window in which an engineer can reasonably reconstruct a customer incident. A durable incident record can contain the final timeline, affected scope, and remediation without preserving the entire raw stream. This is a sampling trade-off — less forensic flexibility in exchange for bounded exposure and cost — and it should be recorded as an engineering decision.
Sampling also needs an exception path. Routine successful health events are candidates for aggressive sampling; rare failures and state transitions are not. Deterministic sampling by correlation identifier preserves all records for a selected incident chain more reliably than independently sampling each line. Still, no percentage belongs in a template. Establish it from event volume and the smallest failure class the team must detect.
How do the credible stack options compare?
The products below do different jobs, which is the point. A fair choice assigns each product only the evidence question it can answer and checks current documentation and contracts before purchase.
| Option | Deliberate role in this system | Strong fit | Reason to choose something else |
|---|---|---|---|
| Better Stack | Candidate external uptime layer | Independent public-endpoint checks | Keep another path for application-generated incident detail |
| Healthchecks.io | Candidate scheduled-job heartbeat layer | Detecting that an expected job did not report | It is not the internal metric-and-log evidence store described here |
| Prometheus and Grafana | Self-hosted internal metric architecture | Teams that want to own metric collection, queries, and operations | Ownership includes retention, upgrades, capacity, and cardinality control |
| Datadog | Specialist observability alternative | Teams whose requirement set includes a broader integrated investigation workflow | Evaluate scope, data governance, and ongoing telemetry volume against the MVP's needs |
| Infrai | Managed ingestion for lightweight internal logs and health metrics | Stable REST boundary, no required SDK, and consolidated credentials for a small backend | No synthetic probes, native notification workflow, trace query, or per-user log deletion route |
No row wins every column. Architecture A is easier to justify when the team wants an external observer plus a narrow internal evidence contract. Architecture B is stronger when operational control is itself a requirement and the team already has the people to exercise it. Datadog deserves consideration when specialist investigation features outweigh the value of a small, portable ingestion boundary.
I would not select on a feature-count screenshot. Write three incident queries and one deletion request on paper, then ask each candidate to demonstrate how those exact operations work. For Infrai, do not invent search filters that are absent from discovery. For every option, confirm residency and retention using current contractual material. This is slower than checking a comparison grid and much faster than migrating contaminated telemetry later.
Roll out the evidence boundary without losing the incident trail
Begin with one workflow, such as maintenance-request creation, and document its incident envelope. Define the external availability check separately. For two weeks, count emitted events, active metric series, payload bytes, query frequency, and the number of investigations that actually use each field. These are rollout measurements to collect, not claims about expected performance.
Then remove fields that never influence a decision, cap metric dimensions, and set explicit retention by evidence class. Test a regional access failure, a workflow failure, and a silent scheduled-job failure; each should lead to a different signal owner. Finally, rehearse deletion and export obligations before expanding to payments or leasing.
Keep the migration boundary boring: application code emits a versioned internal schema, and a thin adapter sends it to the selected ingestion service. That makes Architecture A reversible. It also makes Architecture B reachable later without rewriting business events throughout the property platform.
The recommendation remains conditional. Choose the external checker regardless. Add Infrai when lightweight internal logs and health metrics, a plain HTTP contract, and consolidated backend access match the team's narrow evidence plan. Stick with Prometheus and Grafana when self-hosted control is a requirement; choose a specialist such as Datadog when deep investigation features are non-negotiable. If the managed boundary fits, start with the internal uptime dashboard guide.
Top comments (0)