X · Bug reports

Monitor X for bug reports

Where your outage becomes public first, usually before your own monitoring has finished deciding.

[01] THE JOB/ BUG REPORTS

What bug reports means

Finding problems with your product reported in public — in a thread, an issue on someone else’s repository, or a complaint that never became a support ticket.

What it looks like on X

X is the earliest warning you get and the least detailed. A user hits something broken and says so within seconds, with no version number, no reproduction and no patience. Individually these are almost useless as bug reports; collectively they are the fastest outage detector you have, because volume spikes before anything else does. The second shape is the public complaint aimed at your account, which is a support ticket with an audience and needs answering as one.

What X will not give you

X is where exclude words and the relevance read do the most work. A common-word brand tracked on X without either is a guaranteed way to stop reading your own alerts within a fortnight.

What FishOut collects from X

Public posts, including replies and quote posts, read through X’s logged-out search once a day. Reposts are dropped, and a very busy term is covered only in part.
[02] WHAT TO TRACK/ KEYWORDS

Keyword shapes for bug reports on X

A keyword tuned for this job on another platform is usually silent here, because the same person writes differently in each place. The example beneath is read the way FishOut reads one: a relevance bar and the label it would carry.
keywords · x
your name plus outage words

"down", "broken", "not working", "outage". The spike in this keyword is the signal, more than any individual post.

your name plus "anyone else"

The user checking whether it is just them, which on X happens within seconds rather than after an hour of investigation.

your product name alone, high floor

Needed to catch complaints aimed at you that use no failure vocabulary, and only manageable with a high relevance floor.

X85

is AcmeMail down for anyone else? our whole shared inbox has been showing stale threads for 20 minutes

Has a problem
[03] HOW TO SET IT UP/ VIEWS & ROUTING

The configuration that works here

Be clear about what FishOut is here: X is checked once a day, so your own monitoring is the outage alarm and FishOut is the record. Put a relevance floor of 70 on a support channel, work complaints aimed at you from the Support view, and let the Daily brief’s Spikes flag a day when your name plus outage words jumps far above its 14-day baseline. Public replies matter here in a way they do not on GitHub: a complaint on X is a support ticket with an audience, and the audience is what you are answering.

And what to do with what arrives

To engineering, with no reply drafted. Write an agent: when a brand post is labelled Has a problem or Complaint, or a label you describe such as "Bug report", assign it to an engineer and send it to a webhook — a tracker, not a brand-voice answer.
[04] THE COMMON MISTAKE/ AVOID THIS

Judging posts individually

One X complaint is almost useless as a bug report — no version, no reproduction, no detail. Three in ten minutes is an incident. Teams tune a relevance floor so individual posts qualify, which either floods the channel or, more often, sets the bar so high that the pattern never triggers. Watch the rate, not the mention.

Questions

Bug reports on other platforms

24 of a possible 40. A job and a platform only make a page when the intersection has something true of it alone.