Frequently asked questions

Tend treats any network error, timeout, or 5xx response as a failed attempt and retries with exponential backoff and full jitter. By default a job gets 5 attempts, starting at a 10-second base delay capped at one hour. You can raise this to 25 attempts per job, and you can list response codes, such as 410, that should be treated as permanent failures.

Tend delivers jobs at least once, which means a run can occasionally be attempted twice, for example if your endpoint processed the request but the response was lost. Every attempt carries the same run_id in the Tend-Run-Id header, so you can deduplicate on your side. We recommend making handlers idempotent.

Send an Idempotency-Key header of up to 255 characters on any POST. If we see the same key again within 24 hours with the same body, we return the original response instead of creating a second resource. If the body differs, you get a 409 idempotency_conflict error.

Each delivery includes a Tend-Signature header of the form t=1789430400,v1=<hex>. Compute HMAC-SHA256 over the string <t>.<raw body> using your endpoint's signing secret and compare it to v1 in constant time. Reject deliveries where t is more than 5 minutes from your clock. All three SDKs ship a verify_signature helper.

30 seconds. Expressions that would fire more frequently are rejected with a 422 interval_too_short error. Standard five-field cron is supported, along with a six-field form that adds seconds in 30-second steps.

256 KB after JSON encoding. For anything larger, store the data yourself and pass a reference in the payload. It is also cheaper for both of us.

Tend waits up to 15 minutes for your endpoint to finish handling a run. For longer work, respond quickly with a 202 and report completion by calling the run completion endpoint, or split the job into smaller pieces. Webhook result deliveries to your endpoint time out after 15 seconds.

No. Keys beginning with tnd_dev_ operate on the development environment of a project, and keys beginning with tnd_live_ operate on production. Schedules, jobs, runs, and logs are fully separate. Development runs are metered at 25% of the normal rate against your monthly quota.

Tend runs in us-east (Ashburn), us-west (Hillsboro), eu-central (Frankfurt), and ap-southeast (Singapore). Hobby projects use us-east. Pro and Scale projects can choose a default region, and Scale projects can pin individual jobs with the region field. Data for pinned jobs stays in that region.

On Hobby, the 10,000-run monthly cap is hard. Further requests receive a 429 quota_exceeded error until the next billing cycle. On Pro and Scale we keep running your jobs and bill overage at $0.12 or $0.08 per 1,000 runs respectively, and we email you at 80% and 100% of the included volume.

Hobby keeps run logs for 3 days, Pro for 30 days, and Scale for 90 days. Enterprise plans can retain logs for up to 365 days and export them to a storage bucket you control. Job and schedule definitions are kept until you delete them.

Yes. Upgrades take effect immediately and are prorated. Downgrades and cancellations take effect at the end of the current billing period. If a downgrade would put you over the new plan's schedule limit, existing schedules keep running but you cannot create new ones until you are under the limit.