Whether you're an engineer marking outdated articles based on a product update or part of the customer support team reminding yourself to update some information, marking an article as Stale can keep your product & articles in sync and visitors up to date.
Marking an Article as Stale
You can mark articles as stale immediately or schedule them to go stale in the future. Here's how:


You can choose from a pre-defined amount of time, or choose any date in the future (we recommend this century, though π½).

This helps anyone (including yourself) remember why it was marked Stale in the first place.

This will add the Stale status on your article

What Happens After the Scheduled Date
When the scheduled date arrives:
- The article automatically becomes Stale
- Team members get notified in their weekly Stale email if they have them enabled
- The article & content views show the Stale indicators
Best Practices for Stale
Stale works best when everyone uses it the same way. A little consistency goes a long way, especially as your Knowledge Base grows.
Write Reasons That Help
When multiple team members work on your Knowledge Base, specific reasons help everyone understand:
- What exactly is outdated or incorrect
- How urgent the update is
- What type of changes are needed
- Who might be best qualified to make the updates
Future you will be grateful. So will your teammates.
Examples of Good vs Poor Reasons
Good Reasons (Specific & Actionable) | Poor Reasons (Vague & Unhelpful) |
|---|---|
"Screenshots show old dashboard. UI changed in v2.1 release" | "Needs update" (what kind of update?) |
"API endpoint changed from /users to /accounts, update code examples" | "Old content" (how old, what's changed?) |
"Feature removed in March 2025 update. Article needs complete rewrite" | "Check this" (check for what specifically?) |
"Pricing changed, update all cost references and comparison table" | "Outdated" (what makes it outdated?) |