This is what an AI/RAG pipeline sees when it indexes this page — the same output served at https://camelmind-docs.vercel.app/api/llms/features/last-updated.Back to doc

Rendered doc

Show Last Updated

Display when a documentation page was last updated, and optionally who made the change.

Help readers understand how current your documentation is by displaying the date a page was last updated. You can also show the name of the person who made the most recent change.

CamelMind displays the Last updated footer by default.

To explicitly enable or disable it, update camelmind.config.ts:

ts
site: {
  showLastUpdated: true,
},

To hide the footer on all pages:

ts
site: {
  showLastUpdated: false,
},

When enabled, CamelMind displays the last updated date at the bottom of every documentation page.

Show the author of the last update

To show the author of the most recent change in the footer, enable the showLastUpdateAuthor configuration option:

ts
site: {
  showLastUpdated: true,
  showLastUpdateAuthor: true,
},

Example:

text
🕐 Last updated by Jane Doe on July 22, 2026

When you disable showLastUpdateAuthor, the page shows only the date.

text
🕐 July 22, 2026
Note

showLastUpdateAuthor has no effect when showLastUpdated is disabled.

Override the last updated date in frontmatter

To override the last updated date on a page, add the last_updated field to its frontmatter. This replaces the automatically detected date with your custom date value.

md
---
title: Getting started
last_updated: "2026-06-01"
---

CamelMind displays this value instead of the automatically detected date.

How CamelMind determines the last updated date and author

When you enable showLastUpdateAuthor, CamelMind shows the person who most recently changed the page, based on your site's Git history.

CamelMind checks several sources to find the most recent update date and author. It uses the first source that provides the information:

  1. Page configuration — If the page has a last_updated date in its frontmatter, CamelMind uses that date. This provides a date, but not an author.
  2. GitHub or GitLab — CamelMind checks the repository's commit history through the GitHub or GitLab API. This can provide both the update date and author.
  3. Local Git history — If the documentation repository is available on the build server, CamelMind checks its local Git history.
  4. File timestamp — If no Git history is available, CamelMind uses the date you last modified the file on the build server. This provides a date only, so the site displays no author.

In other words, Git history is what tells CamelMind who made the change. If CamelMind cannot access that history, it can still show a date sometimes, but it cannot determine the author.

Why do I need a GitHub token?

If your repository is private, you may wonder why CamelMind needs a GitHub token when Vercel can already access the repository.

The reason is that Vercel's access to your repository and CamelMind's access to the GitHub API are separate.

When Vercel builds your site, Vercel has its own permission to clone your private repository. CamelMind does not automatically inherit that permission when it makes a separate request to the GitHub API to find the commit date and author.

For a public GitHub repository, CamelMind can query the GitHub API without authentication. For a private repository, GitHub requires CamelMind to authenticate.

If you're deploying a private repository through Vercel, add a GITHUB_TOKEN to your Vercel environment variables. The token gives CamelMind permission to read the repository's commit history so it can determine the correct update date and author.

This is especially important when the build environment does not contain the full Git history, such as with a shallow clone.

When the author or update date may be missing

CamelMind needs access to your Git history to reliably show the person who last changed a page. How much Git history is available depends on how your site is built and deployed.

Private repositories

For a private GitHub or GitLab repository, CamelMind needs its own access token to look up the repository through the GitHub or GitLab API:

  • GitHub: GITHUB_TOKEN
  • GitLab: GITLAB_TOKEN

Your deployment platform may already have permission to download your private repository. That permission does not automatically give CamelMind permission to make its own API requests.

If CamelMind cannot access the API, it tries the next available source.

Self-hosted Git repositories

CamelMind's API lookup supports repositories hosted on:

  • github.com
  • gitlab.com

For self-hosted GitHub Enterprise, self-managed GitLab, Bitbucket, or another Git server, CamelMind skips the API lookup and tries to use the Git history available locally instead.

Sites deployed without a Git repository also skip the API lookup.

Shallow Git clones

Some deployment systems download only the most recent commit instead of the repository's full history. This is called a shallow clone.

With only one recent commit available, CamelMind may not be able to determine when a particular page was last changed or who changed it. In that case, CamelMind falls back to the file's modification date.

That date can be misleading because it may reflect when the deployment system downloaded the file, rather than when someone actually edited the page.

For example, Vercel projects should enable Deep Clone. Other CI systems should avoid options such as --depth or fetch-depth: 1 when checking out the repository.

Docker deployments

If you deploy CamelMind using the provided Dockerfile, the final runtime image does not include the repository's .git directory. This means CamelMind cannot use local Git history.

For Docker deployments, the GitHub or GitLab API is therefore the way to get reliable update dates and authors. For private repositories, make sure the appropriate API token is available to CamelMind.

Branches and preview deployments

When CamelMind uses the GitHub or GitLab API, it looks at the branch configured by repo.branch (main by default).

This means a preview deployment for a feature branch may show the latest commit from main instead of the latest commit from the feature branch.

If your deployment workflow builds documentation from a different branch, configure repo.branch to match that branch.

Current limitations
  • The Last updated footer is configured for the entire documentation site.
  • You cannot currently hide the footer on individual pages.
  • You cannot override the author name using page frontmatter.

What the AI sees

1> For a complete documentation index, see /llms.txt. To read any public page as Markdown, append .md to the URL.
2 
3Help readers understand how current your documentation is by displaying the date a page was last updated. You can also show the name of the person who made the most recent change.
4 
5---
6 
7## Enable the Last Updated footer
8 
9CamelMind displays the **Last updated** footer by default.
10 
11To explicitly enable or disable it, update `camelmind.config.ts`:
12 
13```ts
14site: {
15 showLastUpdated: true,
16},
17```
18 
19To hide the footer on all pages:
20 
21```ts
22site: {
23 showLastUpdated: false,
24},
25```
26 
27When enabled, CamelMind displays the last updated date at the bottom of every documentation page.
28 
29---
30 
31## Show the author of the last update
32 
33To show the author of the most recent change in the footer, enable the `showLastUpdateAuthor` configuration option:
34 
35```ts
36site: {
37 showLastUpdated: true,
38 showLastUpdateAuthor: true,
39},
40```
41 
42Example:
43 
44```text
45🕐 Last updated by Jane Doe on July 22, 2026
46```
47 
48When you disable `showLastUpdateAuthor`, the page shows only the date.
49 
50```text
51🕐 July 22, 2026
52```
53 
54<Callout type="note">
55`showLastUpdateAuthor` has no effect when `showLastUpdated` is disabled.
56</Callout>
57 
58---
59 
60## Override the last updated date in frontmatter
61 
62To override the last updated date on a page, add the `last_updated` field to its frontmatter. This replaces the automatically detected date with your custom date value.
63 
64```md
65---
66title: Getting started
67last_updated: "2026-06-01"
68---
69```
70 
71CamelMind displays this value instead of the automatically detected date.
72 
73---
74 
75## How CamelMind determines the last updated date and author
76 
77When you enable `showLastUpdateAuthor`, CamelMind shows the **person who most recently changed the page**, based on your site's Git history.
78 
79CamelMind checks several sources to find the most recent update date and author. It uses the first source that provides the information:
80 
811. **Page configuration** — If the page has a `last_updated` date in its frontmatter, CamelMind uses that date. This provides a date, but not an author.
822. **GitHub or GitLab** — CamelMind checks the repository's commit history through the GitHub or GitLab API. This can provide both the update date and author.
833. **Local Git history** — If the documentation repository is available on the build server, CamelMind checks its local Git history.
844. **File timestamp** — If no Git history is available, CamelMind uses the date you last modified the file on the build server. This provides a date only, so the site displays no author.
85 
86In other words, **Git history is what tells CamelMind who made the change**. If CamelMind cannot access that history, it can still show a date sometimes, but it cannot determine the author.
87 
88<Callout type="important" title="Why do I need a GitHub token?">
89 
90If your repository is private, you may wonder why CamelMind needs a GitHub token when Vercel can already access the repository.
91 
92The reason is that **Vercel's access to your repository and CamelMind's access to the GitHub API are separate**.
93 
94When Vercel builds your site, Vercel has its own permission to clone your private repository. CamelMind does not automatically inherit that permission when it makes a separate request to the GitHub API to find the commit date and author.
95 
96For a public GitHub repository, CamelMind can query the GitHub API without authentication. For a private repository, GitHub requires CamelMind to authenticate.
97 
98If you're deploying a private repository through Vercel, add a `GITHUB_TOKEN` to your Vercel environment variables. The token gives CamelMind permission to read the repository's commit history so it can determine the correct update date and author.
99 
100This is especially important when the build environment does not contain the full Git history, such as with a shallow clone.
101 
102</Callout>
103 
104<Callout type="important" title="When the author or update date may be missing">
105 
106CamelMind needs access to your Git history to reliably show the person who last changed a page. How much Git history is available depends on how your site is built and deployed.
107 
108### Private repositories {/* toc:exclude */}
109 
110For a private GitHub or GitLab repository, CamelMind needs its own access token to look up the repository through the GitHub or GitLab API:
111 
112- GitHub: `GITHUB_TOKEN`
113- GitLab: `GITLAB_TOKEN`
114 
115Your deployment platform may already have permission to download your private repository. **That permission does not automatically give CamelMind permission to make its own API requests.**
116 
117If CamelMind cannot access the API, it tries the next available source.
118 
119### Self-hosted Git repositories {/* toc:exclude */}
120 
121CamelMind's API lookup supports repositories hosted on:
122 
123- `github.com`
124- `gitlab.com`
125 
126For self-hosted GitHub Enterprise, self-managed GitLab, Bitbucket, or another Git server, CamelMind skips the API lookup and tries to use the Git history available locally instead.
127 
128Sites [deployed without a Git repository](/before-you-begin/deploy-without-git) also skip the API lookup.
129 
130### Shallow Git clones {/* toc:exclude */}
131 
132Some deployment systems download only the most recent commit instead of the repository's full history. This is called a **shallow clone**.
133 
134With only one recent commit available, CamelMind may not be able to determine when a particular page was last changed or who changed it. In that case, CamelMind falls back to the file's modification date.
135 
136That date can be misleading because it may reflect **when the deployment system downloaded the file**, rather than when someone actually edited the page.
137 
138For example, Vercel projects should enable **Deep Clone**. Other CI systems should avoid options such as `--depth` or `fetch-depth: 1` when checking out the repository.
139 
140### Docker deployments {/* toc:exclude */}
141 
142If you deploy CamelMind using the provided `Dockerfile`, the final runtime image does not include the repository's `.git` directory. This means CamelMind cannot use local Git history.
143 
144For Docker deployments, the GitHub or GitLab API is therefore the way to get reliable update dates and authors. For private repositories, make sure the appropriate API token is available to CamelMind.
145 
146### Branches and preview deployments {/* toc:exclude */}
147 
148When CamelMind uses the GitHub or GitLab API, it looks at the branch configured by `repo.branch` (`main` by default).
149 
150This means a preview deployment for a feature branch may show the latest commit from `main` instead of the latest commit from the feature branch.
151 
152If your deployment workflow builds documentation from a different branch, configure `repo.branch` to match that branch.
153 
154</Callout>
155 
156<Callout type="important" title="Current limitations">
157 
158- The **Last updated** footer is configured for the entire documentation site.
159- You cannot currently hide the footer on individual pages.
160- You cannot override the author name using page frontmatter.
161 
162</Callout>

Issues (0)

No AI-friendliness issues found.