first set, phase 1b
Watch any public Discourse forum by URL. Thousands of community forums run Discourse and expose a public JSON API; nobody monitors them well. discatch treats them as a first-class source.
Name the forum with site: in a query and register a catch. discatch reads that forum’s own public JSON search endpoint on the interval you set, keeps the thread context on every result, and pushes new matches to your agent. Any public Discourse forum works; a forum discatch has not seen is added the first time a request names it.
Topics and replies on any public Discourse instance you name, or across the seeded set of well-known forums. Category and time filters, thread context, and reply counts on every result.
Each forum’s own public JSON search endpoint, free, one request per forum. discatch keeps a list of forums, seeded with well-known ones, and adds any public forum the first time a request names it with site:.
One syntax for every source: quotes, AND, OR, NOT, site:, author:, lang:.
query
site:community.example.com ("your product" OR "your competitor")One result, as a catch delivers it: source, author, the post, a prescore, thread context, and a suggested action your agent can act on.
Fresh install on the hosted plan, followed the quickstart, and the first run dies with ECONNREFUSED to localhost:5432. Is there a setting I missed?
Two meanings of discourse, both relevant: online conversation in general, and Discourse, the forum software that powers thousands of community forums with a public JSON API. Nobody monitors those forums well. discatch does, and the name fits.
A catch can name a forum with site:. The planner turns that into that forum’s own search endpoint with after: and category: filters, then re-filters locally so a weaker native search still returns correct results from a larger candidate set.
Every result carries parent_url and the reply count, so a mention in reply seven of a support thread arrives with the thread it belongs to. The forum-triage playbook classifies threads into bug, question, feature request, or praise and files bugs to GitHub with a link back.
discatch keeps a list of forums to fan a request out to. It ships seeded with well-known forums and grows as requests name new ones. A request may name up to 20 forums; the quote prices each. The list includes popular developer community forums, platform support forums, and open-source project forums.
Two threads on meta.discourse.org ask for keyword notifications that the software does not have: thread 59286 ("Watching and sending notifications for keywords?") and thread 83388 ("Keyword filtering"). These are the demand evidence. People who run Discourse forums want keyword alerts. Discourse the software does not provide them. discatch does.
Thousands of product communities run Discourse: the support forums of the platforms you build on, the community forums of your competitors, and the places your own users go when the docs fail them. The software exposes a public JSON API on every instance, and almost nobody in social listening reads it. The pages that rank for "monitor Discourse forums" today are server-monitoring tools and threads on meta.discourse.org asking for keyword alerts that the software does not have.
Watch one forum for your product name
site:community.example.com "your product"Watch a competitor’s forum
site:forum.competitor.com (bug OR error OR "does not work")Search across all known forums
"your product" OR "your-product"Not yet. Discourse is in the first set of sources, phase 1b of the roadmap, and discatch is pre-launch. The API serves the doctor manifest today, and the manifest’s sources_now list is the truth for what is live. When phase 1b ships, catches on this source read Discourse through each forum’s own public JSON API with no provider in the middle.
Any public Discourse forum. discatch ships with a seeded list and adds a forum the first time a request names it with site:<forum domain>.
No. Only forums with public read access. discatch never logs in as you.
The same units as any catch: one alert per firing plus one result per item delivered, and no search unit for the re-runs. Each forum in the request is priced in the quote; catches with zero new results cost nothing.
Up to 20 instances per request. The quote prices each forum, so you see the cost before the call runs.
Yes. The planner maps category filters to the forum’s native search. Combine with site: and your boolean query.
The topic title, the post text, the author, the reply count, the score, and parent_url for replies. Thread context is preserved so you know which topic a reply belongs to.
Syften has a generic /forums page that covers forums broadly. discatch treats Discourse as a first-class source with per-forum watching by URL, site: targeting, and thread context on every result. No other tool in this category has a dedicated Discourse page.
None. Zero listening-vendor pages exist for "Discourse keyword alerts" or "monitor Discourse forums." The results today are server-monitoring tools, an abandoned Discourse plugin, and forum threads on meta.discourse.org asking for keyword notifications.
Yes. The forum-triage playbook watches a Discourse forum by URL, classifies threads into bug, question, feature request, or praise, and files bugs to GitHub Issues with a link back.
discatch ships with a list of well-known Discourse forums, including popular open-source and developer community forums. The list grows as requests name new forums. A bare domain is enough to add one.
Each result is one post. Thread context is preserved: every result carries parent_url, the reply count, and the score. The capture endpoint can fetch the full thread if you need it.
No. Discourse uses per-instance polling, not a firehose. The catch interval determines how often discatch checks each forum. At the tightest interval, the lag is about five minutes plus the API response time.
Last reviewed by Parsa Khazaeepoul, founder, dcouple. Facts from docs/data-sources.md and docs/coverage-matrix.md; status from docs/api.md; the search landscape from docs/seo/keyword-map.md.