Skip to main content

Understand billing limits

How TaskJuice meters compute, storage, traffic, and forms, when overage kicks in, and how to recover from a state-storage freeze.

What this page is about

Every TaskJuice plan bundles a fixed amount of capacity across six metered dimensions. When you stay inside the included envelope, your bill is the headline plan price. When you go over, post-paid overage shows up on the next invoice. When you go far over on the metered dimensions that have caps, the platform throttles writes or pauses them entirely until you prune or upgrade.

This page explains what each meter counts, how overage is charged, and what behavior to expect at each threshold. For the exact inclusion amounts and rates per plan, see Plans and pricing.

What each meter counts

TaskJuice tracks six meters per workspace:

  • Compute time. Wall-clock time your workflows spend executing inside the runtime. Counted in milliseconds, billed in hours. Cold start and queue wait before your workflow runs don't count.
  • Files storage. Bytes of large payloads, file uploads, and workflow artifacts stored on your behalf. Counted at write time against the workspace's current total.
  • State storage. Bytes of workflow state, run history, agent thread memory, evaluation traces, and form-submission records. State storage is hotter data and is treated more strictly than files storage.
  • Custom-domain traffic. Bytes served from custom-branded URLs (your hosted forms, embedded portals, anything pointed at a tenant domain you've added). Counted as outbound bytes from the edge.
  • Form submissions. Each accepted form submission counts as one, regardless of payload size. The body size is enforced separately by the per-plan file ceiling.
  • Forms published. The number of forms currently in the published state. This is a hard cap with no overage; you cannot publish a sixth form on Growth.

The live counts for every meter are on the in-app usage dashboard at /<workspaceSlug>/billing/usage. The dashboard is also where the notification thresholds get reported when they fire.

How overage works

Overage is post-paid. Throughout the billing period, every meter increments on the workspace counter. At period end, TaskJuice sums the overage on each meter, multiplies by the per-unit overage rate for your plan, and sends Stripe a single invoice that includes the base subscription plus per-meter overage line items.

You get notified along the way. At 60%, 80%, and 100% of the included amount on each meter, an in-app banner and an email go to the workspace owners. The notifications are debounced once per meter per hour so a chatty workflow can't spam your inbox.

You can shorten retention on individual workflows to stay inside state storage if you don't need 30 or 90 days of run history. You can't extend retention beyond the plan-tier ceiling, and TaskJuice never silently shortens retention to manage cost. The retention number you set is the contract.

What happens at each threshold

The cap behavior is different per meter because the economics are different per meter. State storage is the strictest because the underlying cost is highest; compute and traffic are more forgiving.

MeterAt 100% includedAt 110%At 200%At hard cap
ComputeOverage chargedOverage chargedOverage chargedPer-workflow circuit breaker may trip on runaways
Files storageOverage chargedOverage chargedSoft throttle on non-critical writes (429)New writes blocked at 10x included
State storageOverage chargedHard freezeAlready frozenAlready frozen
Custom-domain trafficOverage chargedOverage chargedSoft throttle (429)Cached 503 served at 10x included
Form submissionsOverage chargedOverage chargedSoft throttle (429 at ingress)429 at ingress at 2x included
Forms publishedHard cap; no overageAlready cappedAlready cappedAlready capped

A 429 response carries a Retry-After header. Critical paths bypass the throttle: audit-relevant writes, error logs, and the billing meters themselves always succeed so your records remain consistent.

Recover from a state-storage freeze

State storage is the one meter where TaskJuice will pause writes. The freeze lands when your workspace's state storage hits 110% of the included amount on your plan. New writes to run history, agent memory, evaluation traces, form submissions, and audit-relevant ledger entries return a STORAGE_STATE_FROZEN error. Reads keep working: your dashboards, exports, and the in-app remediation page all continue to function.

When the freeze lands, the in-app banner sends you to the storage-frozen page at /<workspaceSlug>/billing/storage-frozen. That page walks you through two recovery paths.

  1. Option A: prune

    Archive workflows you no longer need, delete old evaluation traces, or drop run history older than you need. Each delete reduces the period counter. Once the counter drops below the freeze threshold, writes resume within seconds. The storage-frozen page lists the largest contributors so you can pick the highest-impact pruning targets first.

  2. Option B: upgrade

    The next plan up has more included state storage (Starter 0.5 GB, Growth 5 GB, Scale 25 GB). An upgrade flips your plan through Stripe; new writes succeed within seconds of the plan change landing. If you're already on Scale and need more room, contact support.

The freeze is the safety net, not a billing surface. TaskJuice would rather pause writes than bury you in negative-margin overage. The trade-off is that you have to make a decision (prune or upgrade) rather than letting the bill accumulate, which is the explicit design choice.

Predictability over magic

A few platforms manage their own storage cost by silently shortening tenant retention windows during load spikes. TaskJuice doesn't. The retention you configured on a workflow is the retention you get, all the way up to the plan-tier ceiling. If your state storage trends toward the freeze, you'll see the 60%, 80%, and 100% notifications first; the freeze itself is the last step, not the first.

The pricing model is post-paid for the same reason: knowing what you'll owe at month-end is more important than capping spend in a way that drops events. Overage on the soft-cap meters is bounded by the hard caps documented above, so a runaway workflow can't produce a runaway bill.

Per-workflow knobs that clamp to plan ceilings

Several configurable values clamp server-side to the plan tier so a misconfigured workflow can't escape the envelope:

  • Polling interval floor. Starter polls at most every 5 minutes; Growth every minute; Scale every 30 seconds. Setting a lower number in the trigger config is rejected at publish.
  • Agent iterations. Starter agents stop at 25 iterations per run; Growth at 100; Scale at 500. The orchestrator clamps at runtime as a defense in depth.
  • Loop iterations. Starter loops stop at 1,000 iterations; Growth at 10,000; Scale at 100,000.
  • Approval fanout. A single workflow run can spawn at most 10 (Starter), 50 (Growth), or 250 (Scale) approval tasks. Arrays that resolve to a larger size are clamped with an audit log entry.
  • Webhook body size. Starter accepts up to 1 MiB per request; Growth 4 MiB; Scale 6 MiB. Larger bodies are rejected at the edge with a 413.

The publish-time validator names the field and the plan ceiling when it rejects a config, so the fix is local: shrink the value, or upgrade.

What changes when you downgrade

Plan downgrades take effect at the start of the next billing period. The new (lower) ceilings apply from that moment. If you're on Growth with 4 GB of state storage and downgrade to Starter, your storage will be over the 0.5 GB Starter ceiling on day one of the next period, and the freeze will trip on the next write.

Pre-flight your data before downgrading. Prune retention, archive old workflows, and clear evaluation traces until your usage fits inside the destination plan. The usage dashboard shows current consumption per meter, which is the number to plan against.

Workspaces per account

Account-tier caps limit how many workspaces you can run under one TaskJuice account: Starter 1, Growth 5, Scale 25. The cap is enforced at workspace creation, and it exists so per-plan capacity can't be multiplied by spinning up extra workspaces. An agency that signs its sixth client moves to Scale; that's the design.

Was this helpful?