Short answer: use an external schedule expectation for missed heartbeats, and use error tracking for failures from a checkout job that actually started. For a healthtech workflow running in Europe and the US, cost attribution should be attached to one stable run identity and carried through both signals; neither signal is a substitute for the other.
That distinction matters because a checkout failure is not one event. A job can fail to start, start and stall, finish with an application error, or report success before the durable business action is complete. The alert has to preserve those differences, especially when the team needs to decide which region, workflow, or customer-facing operation owns the cost.
No evidence is also evidence.
Failure boundaries for a scheduled checkout run
The first invariant is an external expectation: if a scheduled unit is due, a component outside the worker must know that it was due. The second is an application boundary: the worker must identify the checkout operation, record its meaningful outcome, and attach the same identity to logs, metrics, and error context. The third is an accounting boundary: an alert must say what was affected without pretending that an infrastructure symptom is a precise invoice.
For example, a nightly reconciliation job might be expected once in Europe and once in the US. “The scheduler invoked a process” proves dispatch. “The process exited with code zero” proves very little about a payment attempt, an authorization record, or a durable ledger write. The success event belongs after the application verifies the intended state transition. The exact verification is domain-specific, and I'm not sure a generic monitor can infer it without an application-level signal.
The failure boundaries should remain visible:
| Observed state | Evidence | Useful attribution | Primary investigation |
|---|---|---|---|
| Missed start | No start signal before the schedule grace period | Region, schedule, deployment, or runtime owner | Scheduler, configuration, startup, and release state |
| Started, no completion | Start exists but the completion deadline passed | Run, checkout batch, dependency, and elapsed time | Stalled process, dependency latency, or termination |
| Application error | An exception or explicit failed outcome was emitted | Run, operation type, tenant scope, and error class | Application path and dependency context |
| Completed | A verified business outcome was emitted | Completed operation and recorded cost dimensions | Reconciliation and downstream reporting |
The table is intentionally less ambitious than a dashboard. It says what each signal can prove and what it cannot. That is a useful boundary when someone asks why a green process metric did not prevent a missed checkout batch.
How should healthchecks and error tracking divide regional cron failure alerts?
Treat the heartbeat as a liveness contract, not as a diagnosis. The scheduled unit receives a stable identity such as checkout-reconcile/eu/2026-08-10T02:00Z; it emits a start event only after it has loaded the configuration needed to identify the work, emits a completion event after verifying the durable result, and emits an explicit failure outcome when application code cannot complete. An external evaluator owns the deadline for the first two cases.
Error tracking belongs inside that path. Its job is to preserve the exception, stack, operation name, and relevant dependency context after execution begins. It cannot report an exception for a process that never started, and it should not be forced to infer absence from an empty log query. A missing heartbeat is a time-based claim made by the scheduler's observer; an error event is an execution-based claim made by the worker.
Region is part of identity, not a label added at the end. If Europe and the US have independent schedules, each requires its own expectation. A global “last run succeeded” aggregate can hide a missing regional run. If either region may perform the same checkout operation, idempotency and duplicate handling belong in the application contract; monitoring does not make a retry safe.
The grace period deserves the same care. It should cover normal dispatch and ingestion delay while remaining shorter than the business deadline. There is no universal value for a checkout workflow, because the acceptable delay depends on settlement timing, customer promises, and the scheduler. Keep the chosen value in the decision record and test the overdue path deliberately.
Attribute cost without turning telemetry into accounting
Cost attribution is the primary decision axis here, but a timestamp alone is not attribution. Every event should carry a compact set of dimensions that the team can reconcile: run_id, region, workflow name, operation type, tenant or account scope where permitted, attempt number, and outcome. Avoid placing payment details or other sensitive health information in an error payload. A checkout monitor needs enough context to route work and explain infrastructure cost, not a copy of the transaction.
The same run_id should connect the heartbeat, application logs, metrics, and exception. That makes it possible to answer questions such as “did the US retry create a second attempt?” and “which reconciliation run consumed the delayed dependency calls?” It still does not turn an event count into a charge. Metering rules, retention, ingestion volume, and provider-specific accounting must be reconciled separately.
A practical cost record can be derived after the run rather than guessed in the alert. Store the dimensions needed for grouping, then join them to infrastructure or service usage during reporting. An alert can say “the Europe reconciliation missed its deadline and has 1,240 pending checkout records”; it should not claim that the missed heartbeat cost an exact dollar amount unless a measured accounting system supports that claim.
One hard rule: do not use customer or payment identifiers as the monitoring key. Use a generated run identity and a permitted business scope. That keeps routing useful while reducing the chance that observability data becomes an accidental data store.
The Python state classifier for one regional run
The important code is the state contract around the durable operation. This Python example is deliberately provider-neutral. A Node.js worker can emit equivalent events, but the classifier should stay independent of the mechanism used to transport them.
from dataclasses import dataclass
from enum import Enum
class Outcome(str, Enum):
MISSED_START = "missed_start"
TIMED_OUT = "timed_out"
APPLICATION_ERROR = "application_error"
COMPLETE = "complete"
PENDING = "pending"
@dataclass(frozen=True)
class RunEvidence:
run_id: str
region: str
deadline_passed: bool
started: bool
completed: bool
application_error: bool
def classify(evidence: RunEvidence) -> Outcome:
if evidence.application_error:
return Outcome.APPLICATION_ERROR
if evidence.completed:
return Outcome.COMPLETE
if evidence.deadline_passed and not evidence.started:
return Outcome.MISSED_START
if evidence.deadline_passed:
return Outcome.TIMED_OUT
return Outcome.PENDING
def main() -> None:
regional_run = RunEvidence(
run_id="checkout-reconcile/eu/2026-08-10T02:00Z",
region="eu",
deadline_passed=True,
started=False,
completed=False,
application_error=False,
)
print(classify(regional_run).value)
if __name__ == "__main__":
main()
The ordering is intentional. An explicit application error is direct evidence and should not be replaced by a weaker timeout inference. A completion event wins only when its producer means “the durable business result was verified,” not merely “the function returned.” The classifier cannot repair a loose success definition.
Keep retries in the model. Attempt two should reference the same logical run while retaining its own attempt number. Otherwise, a late completion from attempt one can make a failed attempt two look healthy, and the cost report can count one business operation as two unrelated events. This is where a small state machine earns its keep.
Short code. Hard contract.
Choosing the boundary for a missed run
Replace error tracking alone with a hybrid whenever “the scheduled work did not happen” is itself an alertable failure. The external expectation detects missing starts and overdue completions; error tracking explains the execution path after it begins. Logs and metrics add correlation and aggregate trends, but neither proves that a job was expected to run unless a separate schedule definition exists.
Error tracking alone is enough for a narrower design: request-driven checkout work, no requirement to alert on absent execution, and an application error boundary that is already explicit. It can also remain part of a broader observability stack when that stack evaluates an external schedule rather than relying on an empty telemetry query. Stick with that simpler arrangement when the business does not have a scheduled obligation to prove.
The hybrid is not suitable when the team cannot operate two distinct ownership paths, protect the monitoring data, or define what “complete” means for the business operation. In that case, first make the schedule and completion contract explicit; adding another alerting product will only hide the ambiguity. A team with strict regional isolation should also keep regional expectations separate, even if the reporting view later combines them.
The rejected option is a single error tracker watching for exceptions and silence. It is tidy, but it cannot observe a disabled schedule or a runtime that never initialized. The valid use case is an execution model where absence is not a failure. For scheduled healthtech checkout reconciliation, missed-heartbeat monitoring and error tracking answer different questions, and cost attribution becomes credible only when both carry the same controlled run identity.
Top comments (0)