If a customer is refused three times in fifteen minutes on the same act on the same site, juudd sends a person an email. Separately, the errors in the panel's secret, credential and hand-over actions carry a link to a report form that already knows the site and the sentence the error showed. Neither one needs the customer to write in first.
That is the decision. The rest of this post is the case that forced it, why the number is three, and what the two doors keep and refuse to keep.
The case: refused three times, then silence
On one day in October a customer's assistant had deployed five times and declared two secrets. The customer opened the panel and typed a name into the secret form that did not match the name rule. They were refused three times in five seconds. Then they did nothing, and the site's chat route answered with a 503 because the key it read was never set.
Three things were true at once, and none of them reached a person:
- The refusals were in the event record, word for word. Nothing on the operator's console said that somebody was still standing in them. The console showed what happened, not who was still stuck.
- The support page names an address. That is on another site, behind a mail client, and it asks the person to copy out the site id, the sentence and the time by hand. The customer did not.
- The refusal named the rule but not the name the customer needed, although the waiting names were one query away. That part was fixed separately.
Two doors, one inbox
The first door is a form the customer does not have to find. It is /report in the panel, in the sidebar and beside those error boxes through a link that says "Still stuck? Tell us". The link carries the site and the sentence the error was showing, so the person sends what we need without copying it out.
The server keeps the site only if it is the caller's own, and drops it otherwise. A report must not fail on a detail the person did not type.
The second door is for the person who never writes. After a refusal from a customer's door (the assistant, the chat, or the panel), the platform counts refusals of that act on that site in the last fifteen minutes. On exactly the third, it emails the operator. An operator's own refusals do not count, because those are ours.
The operator's console also has a Support page. It lists every account whose latest act on a site, in the last fourteen days, was refused. A row empties itself when the account does anything on that site that works. An account refused twice and then successful is not on it. One refused three times that did nothing else is.
Why three
One refusal is the product teaching. A refusal that was followed by a success was followed by it on the very next call, every time we looked. Two is a second try. The one case on record of a customer giving up was three identical refusals and then nothing.
So the number came from the log and not from a guess. It also fires on exactly the third, so a burst sends one email rather than one per retry. A customer still stuck after the window passes sends another, which is the point.
What the report form keeps, and what it refuses
A report is customer-written text held outside a conversation, so the limits are in the code.
- What is kept: what the person typed, the sentence the panel was showing, the panel path they were on, the site if it is theirs, and when.
- What is not kept: nothing the browser sends on its own. No headers, no address, no user agent.
- A report is at most 4,000 characters, and an account can file ten in a day. Every one is an email, and an inbox is what a runaway client would spend.
- Reports are removed after 180 days. The next report's write does the removal, because this repository has no scheduler on purpose.
- A report that is refused, empty, too long or over the daily cap, says so in a sentence, and nothing is sent.
The email to the operator is an announcement of the stored report. If the email fails, the report is still stored and the console still lists it.
What was rejected
- A daily digest of the stuck list. It needs a scheduler. The alert fires on the write that matters, and the list is there for whoever opens the console.
- A mail account just to send one person mail. The operator's own mailbox was already reachable.
- A plain
mailto:link. It does nothing on a machine with no mail program set up, which is most webmail users, and it is what the support page already was.
What is not decided
The customer is never told a person was alerted. The receipt says a person reads every report; the alert is ours. Promising a reply time would break the support page's own rule against promising one. And the refusal sentences in a few places still name an address that was never routed, which this decision records and does not fix.
The rule, once
A customer who is stuck should reach a person whether or not they write in: three refusals of one act in fifteen minutes email the operator, and the panel's error boxes link to a report form that carries its own context. The tools and their refusals are listed in the docs.