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

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.

// 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",
    },
  ],
});

Choosing a window

• Match scroll depth: 7d to 14d suits most hot feeds; keep older content in search or an archive.
• Narrower filters need shorter windows.
• Start conservative, widen later if needed.