Find Future-Dated Hugo Content Before It Goes Live

hugo list future flags every page Hugo thinks is scheduled for later, before a scheduling mistake turns into a live post. It's a read-only CSV audit: path, title, date, draft state and permalink for each match. The examples use Hugo 0.123.7, installed from Ubuntu package version 0.123.7-1ubuntu0.3+esm2.

Allow about ten minutes. You need a shell, a Hugo project, and read access to its content directory. No root, no running web server. This command only lists content: it does not publish, render, edit or delete anything.

1. Check the installed command

Run these ordinary, read-only checks from the machine where the site is built:

$ hugo version
hugo v0.123.7+extended linux/amd64 BuildDate=2026-03-17T19:51:14Z VendorInfo=ubuntu:0.123.7-1ubuntu0.3+esm2
$ hugo list future --help
List all of the posts in your content directory which will be posted in the future.

The subcommand is hugo list future. It carries no command-specific filter or output-format option; everything else, such as --source, --config, --clock, --quiet and --verbose, is inherited from Hugo's parent commands.

2. Run the audit from the project directory

Change into the root of the Hugo project, then run the command:

$ cd /path/to/my-hugo-site
$ hugo list future
path,slug,title,date,expiryDate,publishDate,draft,permalink
content/posts/launch.md,,Launch notes,2099-01-01T00:00:00Z,0001-01-01T00:00:00Z,2099-01-01T00:00:00Z,false,https://example.test/posts/launch/

Swap in your own project root for /path/to/my-hugo-site. The command reads the project's configured content and site settings, then prints a header followed by comma-separated records. Rows, ordering and permalinks depend entirely on the project; a blank result after the header means Hugo found nothing dated for the future.

Do not treat the output as a plain, space-separated list. Titles and other values can contain punctuation, so use a CSV-aware tool if you're automating the audit. The empty slug field above is real: that page just never defined one explicitly.

3. Read the date fields correctly

The comparison that matters is the page's publication date, which shows up in both the date and publishDate columns on this installed release. expiryDate is the expiry value, not the reason the page matched; a zero expiry appears as 0001-01-01T00:00:00Z in the example above.

A page is listed because its publication date sits in the future relative to Hugo's clock. That's a date comparison, not a promise the page is reachable from a production site: draft status, build environment, scheduled deployment and any external publishing process still decide what readers actually see.

Use a controlled clock when you need to reproduce a boundary or compare reports from different days:

$ hugo --clock 2026-09-24T00:00:00Z list future
path,slug,title,date,expiryDate,publishDate,draft,permalink
content/posts/tomorrow.md,,Tomorrow's release,2026-09-25T00:00:00Z,0001-01-01T00:00:00Z,2026-09-25T00:00:00Z,false,https://example.test/posts/tomorrows-release/

The value passed to --clock includes a timezone. Use the same timezone and instant when comparing runs; omit it and Hugo falls back to its normal current clock. Never infer a page's status from its file name or directory alone.

4. Include drafts in your review

Future dates and draft status are separate concerns, and the command happily shows both at once, which is exactly how you catch a planned page that was accidentally left marked draft:

$ hugo list future
path,slug,title,date,expiryDate,publishDate,draft,permalink
content/posts/review.md,,Internal review,2099-02-01T00:00:00Z,0001-01-01T00:00:00Z,2099-02-01T00:00:00Z,true,https://example.test/posts/review/

draft,true is the value that matters here: the page is both future-dated and still marked draft in its metadata. Do not "fix" that mid-audit by editing front matter. Confirm the intended publication date and whether the page should even be publishable first, then make the change through your normal review process.

5. Point Hugo at another project safely

Inspect a project without changing into its directory by passing its root with --source:

$ hugo --source /path/to/my-hugo-site list future
path,slug,title,date,expiryDate,publishDate,draft,permalink
content/posts/launch.md,,Launch notes,2099-01-01T00:00:00Z,0001-01-01T00:00:00Z,2099-01-01T00:00:00Z,false,https://example.test/posts/launch/

Hugo uses the project's own configuration by default. If that configuration lives somewhere unusual, supply the inherited --config or --configDir option, but only once you've verified the path:

$ hugo --source /path/to/my-hugo-site --config /path/to/my-hugo-site/config/hugo.yaml list future

A missing or incorrect source path is an error and returns a non-zero status; the installed command fails outright when the source directory does not exist. Check the path and permissions rather than reaching for sudo, which does nothing to repair a wrong project layout.

6. Save a report without touching the site

Shell redirection writes the command's standard output straight to a new file. Pick a destination outside the project if you want the audit kept separate:

$ hugo --source /path/to/my-hugo-site list future > /tmp/hugo-future.csv
$ test -s /tmp/hugo-future.csv && sed -n '1,5p' /tmp/hugo-future.csv
path,slug,title,date,expiryDate,publishDate,draft,permalink
content/posts/launch.md,,Launch notes,2099-01-01T00:00:00Z,0001-01-01T00:00:00Z,2099-01-01T00:00:00Z,false,https://example.test/posts/launch/

This redirection does not make Hugo publish anything: it only saves the report. Be careful with >, since the shell truncates an existing destination before Hugo even starts. Use a new filename, or copy an existing report first if it matters, and if Hugo exits non-zero, inspect the error rather than treating a partial report as complete.

7. Keep the audit separate from publishing

hugo list future is an inventory command. It does not turn a future date into a live page, and it does not change front matter, generated files or deployment state, which makes it a solid pre-release check in a build review or a scheduled-content report.