Blocklist
Drop spam reports at ingest before they touch your inbox. By email, IP, user-agent or keyword.
Some of your end users will not be sending real bug reports. The blocklist is a per-honeycomb list of rules that get matched at the moment a POST /api/v1/bugs arrives — if any rule matches, the request still returns 201 Created to the reporter (so they don't get a hint that they were filtered) but the report is silently dropped. It never enters your inbox, never fires a webhook, never counts toward your monthly cap.
Manage rules in /{hive}/honeycombs/{id}/settings/blocklist.
Rule kinds
| Kind | Match | Example |
|---|---|---|
email | Exact, case-insensitive, against the reporter email | spammer@example.com |
ip | Exact, against the request's resolved IP | 203.0.113.42 |
user_agent | Substring inside the reporter's User-Agent header | BadBot |
keyword | Substring inside title or description, case-insensitive | casino |
Email and IP matches are exact. User-agent and keyword matches are substring — that's intentional. UA strings are long and structured; you don't want to maintain Mozilla/5.0 ... BadBot/1.2. Keywords are even more clearly substring (you want to catch the word inside any sentence).
Adding a rule
- Pick the kind from the dropdown.
- Enter the value.
- Optionally add a reason for your future self ("spammer 2025-Q3", "regex bypass attempt").
- Save.
Reports matching the new rule are dropped from the next request onwards. Reports already in your inbox are not retroactively removed — use the bulk-mark-spam action for that.
Removing a rule
Trash icon on the row. Confirmation dialog: "Reports matching X will land in the inbox again." Removing a rule re-enables ingest for matches; it doesn't restore previously dropped reports (those were never persisted).
What the reporter sees
Identical 201 response, identical "Thanks!" toast in the widget. No hint that they were filtered. This is deliberate — telling spammers their rule pattern was caught just makes them rotate.
When NOT to use the blocklist
- Genuine duplicates — use the bug detail's Mark duplicate instead. The reporter still gets to log a real ID; you triage it together with the original.
- Rate limiting — that's already handled at the API level per key.
- Test reports — for your own QA, just ignore them in the inbox. Don't pollute the blocklist with rules you'll forget to clean up.
Audit history
The blocklist UI shows when each rule was created and (for matched rules) when it was last hit. We don't surface a per-event log of dropped reports for now — it's high-volume and low-signal. If you need to know exactly which reports a rule blocked, mute the rule (delete it temporarily), watch the inbox, then re-add the rule.