The free month, suspension, deletion

A workspace has a life, and it is a clock rather than a workflow. Once an hour Runjet looks at how much time has passed and decides what that means. The two clocks, and which day is measured against which of them, are the whole of that design.

Two clocks

• From registration only the free month is measured.
• From suspension everything after it: the warnings and the deletion.

If deletion were measured from registration, a customer who paid for a year and then stopped is on day 400 — every deadline would be long behind them and the deletion would arrive on the next tick instead of in thirty days.

Every threshold is "at least this long ago and no message sent yet", never "exactly this many days". A Runjet that was off for a day sends, on startup, what is true, once, and skips nothing.

The free month

Thirty days from registration on the Pro plan, with no card. An email five days and two days before it ends (notifications); a banner in the application counts down the same. Paying ends the month that day — the free period is what you have until you pay, not a discount on the first month (plans). With no payment, day thirty brings a suspension with the reason "the free month ended".

Suspension

Scheduling stops: no tick makes a run, agents keep reporting in and are given nothing, and running by hand is refused. Everything stays readable: jobs, agents, history, outputs. Every change gets a 402 response with the sentence this workspace is suspended — subscribe to make changes again (error responses); in the application a Scheduling has stopped banner says so, with a countdown to deletion.

A workspace arrives here by two routes: the end of the free month without a payment, and the end of a subscription. A failed payment by itself stops nothing — the provider keeps trying the card and only an email arrives; the suspension comes when the subscription ends.

The way out is to pay. Exporting your data works the whole time.

Resuming

Paying brings a suspended workspace straight back — through Billing and a new checkout, also when the workspace was suspended because an earlier subscription ended. The ended subscription is cancelled at the payment provider as the new one takes its place, so no old invoice stays open. As the workspace comes back, Runjet writes a floor for catching up into every job: twenty days of suspension must not look like a twenty-day outage that needs catching up, and nothing that should have run during it runs after the payment.

Deletion

Thirty days after suspension, with emails fifteen, five and two days ahead (notifications). Deletion is a rename: the workspace's address stops answering, nothing signs in, agents cannot get through — and every byte is still in place. A last email arrives: "If this was a mistake, reply to this message within that time and it can be brought back."

Just before the rename, any subscription the workspace still has at the payment provider is cancelled, so nothing is invoiced for a workspace that no longer exists.

Removal

For another thirty days after the deletion the data exists and a reply to that last email brings it back. After that Runjet drops the database and the workspace is gone for good. Those thirty days are a delay, not an exception: an unattended process deciding about somebody else's data from date arithmetic fails quietly, and somebody notices late. Anyone wanting an immediate deletion writes to support.

What arrives along the way

All to the workspace's billing address. A workspace that pays never gets from the left half of this table to the right.