The “Report an Issue” form on the homepage caps the description field at 80 characters. Users sometimes ask why — Twitter let them write 280 long before raising it again, ChatGPT lets them write 4000, why are we still on the typewriter line length?
The number is not a joke. It is the result of three deliberate trade-offs that shaped the moderation profile, the spam profile, and the legibility of the sidebar feed. Every alternative we considered would have been worse on at least one of those axes.
What 80 characters buys you
Three things, each load-bearing.
It forces brevity. The feed on the homepage scrolls vertically; users who scan it during an incident are looking for signal in seconds, not paragraphs. An 80-character cap means every report fits on roughly one line at the dashboard’s typography. The reader can run their eye down the column and absorb thirty reports in five seconds.
A higher cap — even 200 characters — produces visible variance in row height. Some reports become two-line paragraphs. The eye has to slow down. The information density of the column drops. The aggregate cost of going from 80 to 200 is not “longer reports;” it is “reader fatigue across the whole feed.”
It limits the spam vector. Free-text fields are spam magnets. Every length you allow is a length someone will use to inject a URL, paste a banner, run a misleading message. 80 characters is short enough that meaningful spam (“Visit my-scam-site.example.com! 50% off prompt engineering courses!”) consumes most of the field, making the spam syntactically obvious to the reader.
A higher cap allows more sophisticated spam — links wrapped in plausible context, multi-sentence misinformation, copied marketing blurbs. We cannot rely on user-side discrimination to filter all of that out. The cap removes the room those messages need.
It limits moderation cost. A short message space is a small surface to moderate. We do not currently do active moderation — the rate-limit (10 reports per IP per 60 seconds) and the cap together absorb almost all problematic submissions. If we ever needed to add active moderation (we have not, in the time the dashboard has been up), the cost of reading 80-character reports is dramatically lower than the cost of reading 280-character reports. This is a future-proofing benefit that we may never need to cash in, but it costs nothing to keep.
What 80 characters costs you
Genuine costs, in fairness.
It frustrates power users. Engineers who want to be precise — “API returning 500 from us-west-2 only, started 14:32 UTC, retries succeed” — find themselves abbreviating. The cap gets in their way.
It compresses signal. A 200-character report can convey strictly more information than an 80-character one. We lose the marginal precision that the longer field would have allowed.
It can feel arbitrary. Users who hit the cap mid-sentence reasonably ask “why this number.” The number is round and tradition-y rather than mathematically optimal; we picked it because 80 is the historical line length and humans find it natural to read at a glance.
We accept these costs because the readability and spam-resistance benefits are larger than the precision loss. Power users who want to convey detailed structured information are not the primary audience of the sidebar — that audience is engineers in a hurry, who want the gist of what other users are seeing in the next 30 seconds.
Numbers we considered
The internal short-list during design:
- 40 characters. Too short. Most genuine reports could not fit even the basic “API returning 500s in EU” pattern. Would push users into making reports too vague to be useful.
- 80 characters. What we picked. Tight enough to enforce signal, generous enough for the typical real report.
- 140 characters. Old-Twitter shape. Tested in design mockups; row height in the feed visibly varied. Spam vectors started to become viable. Discarded.
- 280 characters. Modern Twitter shape. Discarded for the same reasons as 140 but more so.
- No cap. Discarded immediately. Free-text-no-cap is a spam invitation.
The progression is monotonic on the readability and spam axes — every additional character is a small marginal win for power users and a small marginal loss on the dimensions we care about more.
The rate limit, separately
10 reports per IP per 60 seconds is a separate axis. The cap is about per-message size; the rate limit is about per-source velocity. Both are needed.
Without the rate limit, a single IP could submit 600 reports in a minute, each 80 characters, completely flooding the sidebar with valid-looking but synthetic reports. With the rate limit, the same IP can submit at most 600 reports per hour — still abusable, but the math is now in favor of the dashboard rather than the attacker.
We could go tighter on the rate limit (5 per 60 seconds, or 10 per 5 minutes), but ten-per-minute matches a plausible user behavior pattern. During a real incident, a single user might want to file a report on outage symptoms, then a follow-up on latency symptoms, then a third on a specific component — and a too-tight rate limit would block legitimate reports from that user.
What this design does not do
Worth flagging the things 80-char-plus-rate-limit deliberately does not solve.
It does not prevent collusion. Many IPs can each submit at the legal rate, and produce a spike that is not real. We do not have a strong signal against coordinated reporting. Mitigations are possible (CAPTCHA, login walls, IP reputation) but each costs something — friction, privacy, infrastructure — that we have so far chosen not to pay. The current trust assumption is that real users outnumber adversarial users by a wide enough margin to make individual collusion unrewarding.
It does not weight reports. Every report counts the same in the count buttons. We could imagine weighting by IP-reputation, by user-history, or by content quality. None of those are currently implemented. The displayed counts are unweighted, the sorting is by recency, and the reader is responsible for reading the count alongside other signals.
It does not validate truth. A report saying “API down in Tokyo” cannot be cross-checked. We display it. The reader brings their own validation.
These are intentional. The sidebar is a low-stakes, low-fidelity, fast-moving signal. Adding sophistication would change its character. We would rather have a noisy, fast, simple signal that readers learn to read with judgment than a quieter, slower, more sophisticated one that readers trust without judgment.
When 80 stops being right
The cap is not sacred. If we ever found that the dominant complaint about the sidebar was “I cannot say enough,” we would revisit. So far the dominant complaints are about latency in display, freshness of the trend chart, and clarity of the rate-limit error message — not about the cap. Until that changes, 80 stays.
The general lesson, beyond this site: every input field on a public form is a design choice with consequences for the rest of the system. The number on the cap is doing more work than it looks like.