// Bound a filtered current_feed scan to the last 14 days.
await client.feeds.createFeedGroup({
id: "team_updates",
activity_selectors: [
{
type: "current_feed",
filter: {
search_data: { $contains: { category: "announcement" } },
},
cutoff_window: "14d",
},
],
});Cutoff Date
Some activity selectors have no cutoff by default and scan your feed's entire history on every read. That's fine in development, but with a filter on a large production dataset it becomes a performance risk.
Without a filter, the newest activities are usually enough and the read is fast. Add a filter with no cutoff and the search has no time bound: a selective filter (few or no recent matches) can scan huge amounts of history and time out with a 500, often only after launch once data has grown. A cutoff_window bounds the scan, so a selective filter returns "nothing in the window" quickly.
Rule of thumb: if a selector uses a filter that runs at read time, set a cutoff_window.
Which selectors need this
| Selector | Default cutoff | Set a cutoff when filtering? |
|---|---|---|
following | none (unbounded) | No (only fast tag filters allowed) |
current_feed | none (unbounded) | Yes, with richer filters |
proximity | none (unbounded) | Yes |
follow_suggestion | none (unbounded) | Yes |
query | 7d | Recommended if you widen it |
popular | 7d | Recommended if you widen it |
interest | 2d | Recommended if you widen it |
current_feed supports richer filters (search_data, text, near) that force read-time computation: the path a cutoff protects.
How to set a cutoff
Set cutoff_window on the selector: a relative duration ("the last N ..."). Units: s, m, h, d, w, y (for example "12h", "7d", "2w"); minimum 1 hour.
Choosing a window
- Match scroll depth:
7dto14dsuits most hot feeds; keep older content in search or an archive. - Narrower filters need shorter windows.
- Start conservative, widen later if needed.
Set a cutoff_window on filtered read-time selectors before production: current_feed, query, proximity, and follow_suggestion.