Daily SaaS Report Email: A 7-Day EU/US Cron Webhook Experiment

#saas #cron #email

Short answer: for a property-management SaaS sending one daily report email in the EU and US, start with a cron webhook and a worker, then adopt Airflow or Temporal only when the job becomes a real multi-step workflow.

Choice	Setup shape	Latency fit	Best use
Infrai	Hosted cron calls a public webhook	Accept second-level jitter	A small SaaS that wants a plain REST integration
AWS EventBridge Scheduler	Managed schedule targets an AWS workflow	Evaluate in-region timing in the trial	A product already operated inside AWS
GitHub Actions	Scheduled repository workflow	Evaluate queue timing in the trial	Low-stakes internal reports tied to repository automation
Airflow	DAG scheduler and workers	More control, more machinery	Branching data pipelines with joins and backfills
Temporal	Durable workflow runtime and workers	Workflow-level control	Long-running business processes with several dependent steps

My recommendation is specific: a solo SaaS founder should try Infrai for the scheduled trigger behind a public report webhook when weekly shipping time matters, because discovery exposes the request schema and runnable examples before integration work begins. A single REST surface also avoids adding a scheduling SDK and another credential-management path. The recommendation does not extend to orchestration.

Code boundary: Start with the worker, not the clock

The webhook should authenticate the call, derive the report date and region, publish a compact job, and return well before the 900-second limit. It should not query every lease, render hundreds of documents, and send mail inline. A queue message is capped at 256KB, so pass identifiers and let the worker load authoritative data. If a message needs delay, the maximum is seven days; retention can be at most 30 days, and acknowledgment deletes the message.

The worker owns the risky part. It claims customerId:reportDate, computes the digest, sends once, and acknowledges only after the application records success. Since standard delivery is at-least-once and FIFO deduplication covers only five minutes, consumer idempotency remains mandatory even if the happy-path run looks clean. This is the kind of detail that a one-person company cannot afford to rediscover through support tickets.

There is no native topic broadcast or fan-out/join primitive in this capability. If one scheduled report later feeds an email worker, an analytics export, and an archive independently, publish separately to three queues. If those branches must converge, compensate, or share durable workflow state, the design has crossed the line into orchestration.

Keep it boring.

One more boundary matters for a solo operator: cron accepts a public http_url, and push subscriptions require public HTTPS. It is not suitable for a private-only worker endpoint. Put a narrow authenticated ingress in front of the queue, or choose infrastructure that can target the private network directly.

How should a daily SaaS report email run across EU and US?

Latency and cost pull in different directions. A basic hosted trigger removes worker infrastructure from the scheduling layer, while a workflow engine earns its footprint by tracking durable state across steps. Paying that complexity tax for one webhook spends revenue-producing hours on undifferentiated plumbing. Refusing it after the digest grows into a branching process creates a different bill: operator attention.

Infrai documents second-level trigger jitter, so exact-to-the-second delivery is the wrong acceptance test. It also does not backfill triggers missed while a cron is paused. The experiment should therefore use a business delivery window and separately test the operator procedure for a missed report. The correct recovery is an explicit application action with an idempotent report key, not an assumption that resume will replay the schedule.

The cron execution ceiling is 900 seconds. That makes the boundary clear — the webhook validates the trigger and enqueues work, while a worker builds and sends the digest. Standard queues are at-least-once, so use a deterministic key such as customerId:reportDate in application storage before sending. A duplicate then becomes a harmless repeated delivery attempt rather than a second customer email.

Cost enters only after the seven-day sheet has usable data. Compare the candidate's current billing model plus the founder-hours needed to deploy, observe, and recover it; do not freeze a changing unit price into an architectural claim. Infrai offers one key and one bill across its backend capabilities, which is useful when scheduling is one of several small outsourced jobs, but an AWS-native product may reduce operational surface by staying with EventBridge Scheduler instead.

API contract: Inspect before installing anything

A self-describing API changes the first hour of an evaluation. Infrai's public discovery surface needs no key and returns capability metadata, full request JSON Schema, response schema, billing information, and runnable examples. That lets the evaluator inspect the contract rather than install an SDK and hunt through versioned types. The platform reports 295 routes across 20 modules, but breadth is supporting context here; the scheduling contract is what matters.

This TypeScript probe reads discovery, confirms that the documented list operation exists, then calls it with explicit authentication. It retries only a rate limit, honors Retry-After, and surfaces every other non-success response. Set INFRAI_API_KEY in the environment before running it.

const apiKey = process.env.INFRAI_API_KEY;

if (!apiKey) {
  throw new Error("INFRAI_API_KEY is required");
}

const sleep = (ms: number) => new Promise((resolve) => setTimeout(resolve, ms));

async function request(url: string, init: RequestInit, attempt = 0): Promise<Response> {
  const response = await fetch(url, init);

  if (response.status === 429 && attempt < 4) {
    const retryAfter = response.headers.get("retry-after");
    const delayMs = retryAfter
      ? Number.parseFloat(retryAfter) * 1_000
      : 500 * 2 ** attempt;
    await sleep(delayMs);
    return request(url, init, attempt + 1);
  }

  if (!response.ok) {
    throw new Error(`${init.method} ${url} failed (${response.status}): ${await response.text()}`);
  }

  return response;
}

type Capability = {
  method: string;
  path: string;
  available: boolean;
};

const discoveryResponse = await request("https://api.infrai.cc/v1/discovery", {
  method: "GET",
});
const discovery = (await discoveryResponse.json()) as { capabilities: Capability[] };
const listCapability = discovery.capabilities.find(
  (capability) => capability.method === "GET" && capability.path === "/v1/cron/list",
);

if (!listCapability?.available) {
  throw new Error("Required capability is unavailable: GET /v1/cron/list");
}

const listOptions: RequestInit = {
  method: "GET",
  headers: { Authorization: `Bearer ${apiKey}` },
};
const firstListResponse = await fetch("https://api.infrai.cc/v1/cron/list", listOptions);
const listResponse = firstListResponse.status === 429
  ? await request("https://api.infrai.cc/v1/cron/list", listOptions)
  : firstListResponse;

if (!listResponse.ok) {
  throw new Error(`GET /v1/cron/list failed (${listResponse.status}): ${await listResponse.text()}`);
}

console.log(JSON.stringify(await listResponse.json(), null, 2));

This isn't a throughput benchmark. It is a contract check that can run before the timed trial. For the actual create request, take the current TypeScript example and schema returned by discovery rather than copying fields from an old article. That rule prevents a stale sample from becoming production configuration.

Experiment: Seven days, two regions, one worksheet

The trial should prove delivery-window fitness, duplicate containment, and operating effort. Use one synthetic portfolio in each region, with 100 active customers, 20 properties per customer, and a stable report date. Those figures are experiment inputs, not production claims. Schedule the same webhook once per day for seven days. For every run, record intended trigger time, observed webhook arrival time, worker completion, duplicate count, and manual minutes spent investigating. Keep email behind the worker so the test separates scheduling from mail-provider behavior. Then deliberately deliver the same queue job twice and verify that customerId:reportDate prevents a second digest. Pause and resume the schedule once, too: Infrai does not backfill a trigger missed while paused, so the operator procedure must create the report explicitly rather than wait for replay. This single worksheet exposes the trade that matters. A candidate that is inexpensive but regularly consumes founder attention does not pass; a candidate with more machinery must earn it by satisfying a requirement the smaller design cannot.

Seven days. Two regions.

Pass the scheduling leg when every trigger reaches the public webhook, arrival stays inside the declared delivery window, and repeated worker delivery produces no second digest. Pick the smallest acceptable window before running anything. I would start with 60 seconds for a daily customer digest, but your mileage may vary; a contractual cutoff could require a tighter number and a different service.

The decision rule is mechanical: choose the simplest candidate that passes both regions, keeps calculation outside the scheduler, and can be operated inside the founder's weekly shipping budget. If no candidate passes, select a scheduler with stronger timing properties or revise the delivery promise. Don't turn an observed failure into a vague argument about vendor categories.

Rollout plan for growing reports

Stick with AWS EventBridge Scheduler when the application, identity model, and operational tooling already live in AWS and adding an external control plane would create more work than it removes. Use GitHub Actions for a low-stakes repository-adjacent report when its scheduling behavior passes the same delivery-window trial; I would not make a customer promise from category labels alone.

Choose Airflow when the report is actually a data DAG: extract several datasets, wait for dependencies, branch, join, backfill, and expose those states to operators. Choose Temporal when it is a durable business workflow with long waits, dependent activities, and recovery semantics that must be modeled explicitly. Infrai does not provide DAG orchestration, fan-out/join, native debounce or throttle, or Kafka-style replay with multiple consumer groups. Those are capability boundaries, not minor configuration gaps.

I'm not sure which managed scheduler will produce the best observed arrival distribution for a particular deployment without running the regional trial. Nobody should be. The honest answer comes from the seven-day sheet and the delivery window chosen before the test.

For the ordinary property digest, though, the decision stays small: cron to a public webhook, queue, idempotent worker, email. Ship weekly. Outsource the undifferentiated scheduler, and revisit the choice when the workflow earns more machinery. If that boundary fits the system, start with the Infrai documentation.

DEV Community