> ## Documentation Index
> Fetch the complete documentation index at: https://docs.37audits.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Stack Freshness Auditor

> Flags software stack entries nobody has reviewed for months

<Info>
  **Security Auditor**: checks when each entry of the project's software stack was last entered, edited or confirmed. It warns after 90 days and fails after 180 days. Both limits can be changed.
</Info>

<CardGroup cols={2}>
  <Card title="Accurate alerts" icon="bell">
    The CVE and End of Life auditors read the declared stack. If that stack is out of date, their alerts describe software the site no longer runs.
  </Card>

  <Card title="One click to confirm" icon="circle-check">
    If an entry is still correct, **Still accurate** on the project page resets its date without changing it.
  </Card>
</CardGroup>

This auditor does **not fetch the monitored URL**. It reads the **software stack** of the project and the date each entry was last updated.

## How it works

1. **Read the stack.** An empty stack is a `WARNING` (`300`): nothing can be audited, and the other stack-based auditors cannot run either.
2. **Read each entry's date.** The date changes when an entry is added, when it is edited, and when an admin clicks **Still accurate** on the project page. If an entry arrives without a date, the result is `ERROR` (`500`) and the age rules do not run.
3. **Measure the age.** The age is the number of whole days between the entry's date and the moment the audit runs.
4. **Apply the thresholds.**
   * An entry `failDays` days old or older (default 180) is a `FAIL` (`400`).
   * An entry `warningDays` days old or older (default 90), but younger than `failDays`, is a `WARNING` (`301`).
   * Each entry gets its own check. The oldest entry is listed first.
5. **Aggregate.** `ERROR` wins, then `FAIL`, then `WARNING`. If every entry is younger than `warningDays`, the result is `SUCCESS` (`200`).

## Preferences

Both preferences are optional and set per URL. A value that is unset, unreadable or not positive uses the default. If `warningDays` is not smaller than `failDays`, there is no warning window, so only the `FAIL` rule applies.

| Key | Type | Default | Meaning |
| - | - | - | - |
| `warningDays` | integer | `90` | `WARNING` (`301`) when an entry is this many days old or older |
| `failDays` | integer | `180` | `FAIL` (`400`) when an entry is this many days old or older |

## What it audits

Every row maps to one `checkRule*` method and one `CheckCode`. The audited page is not fetched, so there is no `590` (site blocked) code.

| CheckCode | Status | When it fires | Recommendation | Why it matters |
| - | - | - | - | - |
| <a id="37A-StackFreshnessAuditor-300" />`37A-StackFreshnessAuditor-300` | `WARNING` | The project declares no software stack. | Add the platform, its version and the main components `{url}` runs on to the project's software stack, so that CVE, End of Life and Stack Freshness can audit them. | Without a declared stack, the audits that look for known vulnerabilities and end-of-life software cannot run, so those risks go unreported. |
| <a id="37A-StackFreshnessAuditor-500" />`37A-StackFreshnessAuditor-500` | `ERROR` | A stack entry arrived without its update date. | Run the audit again; if `{software}` still has no update date, contact 37 Audits support. | — |
| <a id="37A-StackFreshnessAuditor-400" />`37A-StackFreshnessAuditor-400` | `FAIL` | A stack entry was last reviewed at least `failDays` days ago. | Confirm the site still runs `{software}`: update the version in the project's software stack if it changed, or click Still accurate if it did not. | Stack information this old most likely describes software the site no longer runs, so vulnerability and end-of-life audits report on the wrong versions. |
| <a id="37A-StackFreshnessAuditor-301" />`37A-StackFreshnessAuditor-301` | `WARNING` | A stack entry was last reviewed at least `warningDays` days ago, but fewer than `failDays` days ago. | Confirm the site still runs `{software}`: update the version in the project's software stack if it changed, or click Still accurate if it did not. | Sites are upgraded and patched over time; stack information nobody has reviewed may no longer match the site, so vulnerability and end-of-life alerts can be wrong or missing. |
| <a id="37A-StackFreshnessAuditor-200" />`37A-StackFreshnessAuditor-200` | `SUCCESS` | All rules passed. The message is `All {n} stack entries were reviewed within {warningDays} days (oldest: {software}, {days} days).` | — | — |

Example messages, using the default thresholds:

* `400`: `Liferay DXP 7.4 U92 was last reviewed 731 days ago (2024-10-13); the limit is 180 days.`
* `301`: `nginx 1.25 was last reviewed 120 days ago (2026-06-16); review it every 90 days.`
* `200`: `All 3 stack entries were reviewed within 90 days (oldest: Liferay DXP 2026.Q1.13 LTS, 42 days).`

Each finding carries the same values in `data`: `vendor`, `product`, `version`, `updatedAt`, `ageDays`, `thresholdDays`, `entries`, `warningDays` and `failDays`.

## Output documentation

| Status | Description | Test logic |
| - | - | - |
| **SUCCESS** | Every stack entry was reviewed within `warningDays` days | No rule fired (`200`). |
| **WARNING** | The stack is empty, or an entry is due for review | No entries (`300`). An entry is at least `warningDays` days old and younger than `failDays` (`301`). |
| **FAIL** | An entry has not been reviewed for `failDays` days or more | An entry is at least `failDays` days old (`400`). Any `301` warnings are listed as well. |
| **ERROR** | The age of an entry could not be measured | An entry arrived without an update date (`500`). |

## Risks and considerations

### The stack is declared, not detected

* 37 Audits trusts the stack the project declares. The CVE and End of Life auditors match vulnerabilities and support dates against those versions. If the stack is out of date, those audits can raise false alarms or miss real problems.
* This auditor does not compare the declared version with what the site actually runs. It only says when someone last looked.

### What counts as reviewed

* Adding an entry, editing it, and clicking **Still accurate** all reset its date. Nothing else does: running other audits, or changing a different entry, leaves the date as it is.
* Pick thresholds that match how often the site is deployed. A site that ships every week may want a `warningDays` of 30.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.