We're busy updating our docs, some areas (especially Settings) may be out of date
Skip to main content
Support

Marking Articles as Stale

Learn how to mark HelpDocs articles as Stale now or on a schedule, add clear reasons, and follow best practices to keep your Knowledge Base accurate and up to date.

River Sloane
Updated by River Sloane
2 min read
Table of Contents

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.

πŸ€” Not sure what a stale article is or when you should use it? Head over to Getting Started with Stale Articles.

Marking an Article as Stale

You can mark articles as stale immediately or schedule them to go stale in the future. Here's how:

The HelpDocs editor toolbar highlighting the Stale status clock icon next to the green Publish button
Head to an article, then click the Stale button
If you're on a smaller screen, click the Article details icon first, then choose Stale Status from the menu
Set article to go stale modal with a calendar picker and 30 days selected.
Select Now or Schedule a date in the future

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

A stale reason text box explaining that the app store flow has been updated
Write a Stale reason

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

Choose one of the pre-defined common reasons to save yourself some time.
Click Set stale now / Click Set stale in x

This will add the Stale status on your article

Click Save to apply Stale status
Your Stale status won't apply until you hit Save on the article editor.

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?)

What did you think of this doc?

Previous Marking an Article as Fresh

Get in touch