A launch morning waits ten minutes. A looping script is paused
Rutba Relay now counts the deliveries each organization started in the last hour. Just over its ceiling, a publish is told to wait ten minutes. Four times over is not a person, and that organization’s publishing is paused until somebody looks.
· 4 min read
A publishing service has two kinds of heavy user, and from the outside they look identical for about ten minutes. One is a brand on launch morning, pushing forty posts to eight networks in an hour because that is what launch mornings are. The other is a script with a bug in its retry loop, pushing the same post to the same accounts until somebody notices.
The first should be slowed down politely. The second should be stopped, because of whose accounts it is burning — and that is the part most customers never think about.
Why one customer’s loop is everybody’s problem
Rutba Relay publishes to social networks through platform apps that the deployment holds — registered with each network, reviewed by each network, and carrying rate ceilings each network sets. Every customer publishing through the Relay publishes through those apps. So a runaway script does not only use up one customer’s allowance. It spends a ceiling that belongs to every customer on the deployment, and it puts an app review that every customer depends on at risk.
A monthly allowance would catch that on most plans, eventually. It does not bind a plan with unlimited posts, and “eventually” is measured in the same hours the damage is done in.
An hourly ceiling per organization
Beside the monthly allowance, the Relay now counts the deliveries an organization started in the last hour. Creating a post that goes straight out and publishing one both check that count. Drafting does not — a draft reaches no network, so a team preparing a hundred posts for next week is not slowed down by it.
| Deliveries in the last hour | What happens |
|---|---|
| Under the ceiling | Publishes, as it always did |
| Just over it | Refused as rate limited, with a ten-minute wait before trying again. Nothing is paused, and nothing else about the account changes |
| Four times over | The organization’s publishing on the Relay is paused by a switch, with the reason written on it, until Rutba staff look and clear it |
Just over the ceiling is almost always a person having a busy morning, so the answer is a wait and a retry time rather than an error. Four times over is a script, and the answer is a stop — with a message saying that publishing for the organization is paused for unusual volume, and that support will look at it and resume it.
A switch, not a suspension
The pause uses the same switches staff throw during an incident — the ones with a name and a clock on them. This one is thrown at the organization’s scope, names the guard that threw it, and records how many deliveries were started against which ceiling. Unlike an incident switch it has no expiry: it stays until a person has looked. Staff clear it from the management console once they have looked.
What it deliberately does not do is suspend the organization. A Rutba organization is the same organization across every product it uses; suspending it because of a publishing loop would take away its mail, its books and its storefront for a bug in one script. Only its Relay publishing stops.
Why this was a port, not an invention
The standalone Relay API had this guard. When the Relay moved onto Rutba’s shared management backend, the guard did not make the move with it — the kind of gap a rewrite leaves, where everything anybody tested came across and the thing that only fires on a bad day did not. It has been put back, and the Relay’s own check suite now covers both outcomes: just over refused with a wait, and far over paused by a switch staff can clear.
Rutba Relay
Publishing to every connected network, run as infrastructure other people depend on.
relay.rutba.io
