# The True-Age Application Run, From Reposted Listing to First-Batch Send

*Trace any listing to its ATS record and real first-published date in under two minutes, then sort and send the day's queue by true age.*

- Canonical URL: https://www.refolk.ai/candidates/guides/true-age-application-run
- Pillar: Reading the market
- Format: Playbook
- Published: 2026-10-20
- Last reviewed: 2026-10-20
- Reading time: 19 min
- Keywords: how to find original job posting date, linkedin reposted job meaning, how soon to apply after a job is posted, is it too late to apply to a job posted two weeks ago, check real posting date on company careers page

## Key takeaways

- A job board's "posted X ago" counter dates the board's copy of a listing, not the employer's original requisition, so late copies, promoted renewals, and reposts all make old jobs look new.
- Ashby documents its publishedAt field as the time a job was last published, so on Ashby only your own first-seen log can prove a listing is genuinely fresh.
- On one Greenhouse board, 232 postings shared just 29 distinct updated_at values, so read first_published and never sort by updated_at.
- In Refolk's index, 530 US recruiter and talent acquisition profiles list Workday as a skill, against 122 for Greenhouse and 23 for Lever, so plan on reading the Workday detail record for most listings you trace.
- Ashby's analysis of 13 million applications found a posting's first week draws 2-2.5x the applications of each later week, which is why a repost puts you into a pool that is already full.
- Sort the queue into fresh (0-96 hours of true age), active (4-10 days), late (10-30 days), and stale-repost (over 30 days or flagged), and give each window its own action: fast send, tailored send, referral-first, or a ghost-job check.

This is the morning procedure for anyone whose job queue is full of listings that all claim to be two days old. For each listing, you trace it back to the employer's applicant-tracking record and read the real first-published date. Then you sort the queue into four age windows and send every genuinely fresh application before the first review batch fills. Budget about 15 minutes of fixed work per run, plus roughly three minutes per listing.

## Why "posted 2 days ago" is not the job's real age

A job board's "posted X ago" counter tells you when that board's copy of the listing was created or renewed. It does not tell you when the employer first opened the role. Several routine mechanisms reset the counter without the job being new.

Two terms first:

- An **applicant-tracking system (ATS)** is the software an employer uses to publish openings and collect applications. The careers page is usually its public front end.
- A **req ID** (requisition ID) is the employer's own identifier for one opening. It usually survives a repost.

These mechanisms make an old job look young:

- **Late copies.** Sometimes an integration or a recruiter adds the job to LinkedIn after it has gone live on the careers page. In that case the board's clock starts when the copy was made, not when the job first went up.
- **Promoted renewals.** According to a secondary summary of LinkedIn's help pages, renewing a promoted job changes its posting date.
- **Closed-job reposts.** LinkedIn also lets employers repost a closed job as a new posting. Earlier applicants stay reachable through the closed post. The "Reposted" tag is the visible trace, and the employer may already hold a full pile of candidates from the first run.
- **ATS auto-renewal.** Secondary sources claim ATSs are commonly set to refresh a listing after a fixed number of days, often 30. No vendor document I found states a default schedule. Treat this as unverified and test for it in step 4.
- **Lower-bound labels.** Workday career sites collapse older listings to "Posted 30+ Days Ago". That is a floor, not a date.
- **No label at all.** ByteDance and TikTok careers pages publish no date.

I found no primary documentation from Indeed or Glassdoor on what their age labels measure. Until you can check one, treat any aggregator's age as the age of its copy.

This matters because of where the applications pile up. Ashby analysed 13 million applications and found that the first week of a posting draws 2-2.5x the applications of each later week. So when a "Reposted" label appears on LinkedIn, it usually means you have arrived after the busiest week, not before it.

> **Rule:** Date from the source record, never the board
>
> A listing's true age runs from the ATS's first-published date or from your own first sighting of its req ID, whichever is earlier. The board's counter is only a lead to follow.

## Where the real first-published date lives in each ATS

The true date sits in the ATS's public job feed or on the job's detail page. The field holding it has a different name and meaning in each system. Of the four common systems, only one documents a date field that resets on republish, and one hides the date behind a detail click.

| ATS | Public list date | Field to trust | Resets on republish? |
|---|---|---|---|
| Greenhouse | updated_at | first_published | Not documented |
| Lever | createdAt | createdAt | Not documented |
| Ashby | publishedAt | publishedAt (last published) | Yes, by definition |
| Workday | "Posted 30+ Days Ago" | startDate / datePosted | Not established |

How to read each one:

- **Greenhouse.** You can recognise it by `boards.greenhouse.io` in the URL or a `gh_jid` parameter on the employer's careers page. The public feed is `boards-api.greenhouse.io/v1/boards/{token}/jobs`, where the token is the employer's board name from the URL. Read `first_published`. Ignore `updated_at`: on one board, 232 postings carried only 29 distinct `updated_at` values, the signature of a bulk edit. The field name says "first", but I found no vendor statement that a repost leaves it alone.
- **Lever.** The host is `jobs.lever.co`, and the feed is `api.lever.co/v0/postings/{site}?mode=json`. Read `createdAt`. It is a Unix timestamp in milliseconds, so divide by 1,000 before converting it to a date, or the conversion will come out wrong.
- **Ashby.** The host is `jobs.ashbyhq.com`, and the feed is `api.ashbyhq.com/posting-api/job-board/{slug}`. Ashby's own docs define `publishedAt` as the ISO date-time "when the job was last published". This field cannot prove a listing is fresh. Only your first-seen log can.
- **Workday.** The host is `myworkdayjobs.com`, and the list view shows only relative text. Open the job's detail page instead. The detail record carries `startDate`. The page source also contains a JSON-LD block, a machine-readable schema.org JobPosting snippet, which carries `datePosted`; search the source for that word. Whether a Workday repost resets either value is not established.

For LinkedIn listings, When This Job Was Posted is a public tool that links a LinkedIn listing to its ATS date. For a cached copy of a careers page, use the Wayback Machine at web.archive.org.

#### Where a listing's date comes from

1. **Board label** - "Posted 2 days ago" on a job board, dating the board's copy
2. **Careers page** - The employer's listing, with its req ID and sometimes a date
3. **ATS public feed** - first_published, createdAt, publishedAt, or the Workday detail record
4. **Your first-seen log** - The date you first captured this req ID, the one repost check that works on every ATS

*Each layer down sits closer to the employer's own record, and only the bottom layer is fully under your control.*

> **Watch out:** Ashby's own date can make a recycled job look new
>
> Ashby defines publishedAt as the last publish time, so a republished req reads as brand new. Before you mark an Ashby row fresh, search your earlier captures and a cached copy for the same req ID or title.

### Which ATS you will trace most often

In Refolk's index of professional profiles, US recruiter and talent acquisition profiles list Workday as a skill far more often than Greenhouse or Lever.

| ATS skill | US recruiter profiles | Share of the three | Multiple vs Lever |
|---|---|---|---|
| Workday | 530 | 78.5% | 23.0x |
| Greenhouse | 122 | 18.1% | 5.3x |
| Lever | 23 | 3.4% | 1.0x |

These counts measure self-reported skill tags on profiles titled "Recruiter" or "Talent Acquisition". They are not ATS market share. The direction is still useful for planning: the Workday detail-record step is the one you will run most.

**530 - US recruiter and talent acquisition profiles in Refolk's index listing Workday as a skill**

That is 4.3x the 122 listing Greenhouse and 23x the 23 listing Lever, so expect most traced listings to need the Workday detail page.

## How fast applications arrive after a job is posted

About half of a short listing's applications arrive within 48 hours, and the first week draws 2-2.5x the volume of each later week. Interview odds appear to drop sharply after about 96 hours. That last figure comes from one study whose primary source I could not retrieve, so treat it as directional.

| Window | Figure | Source |
|---|---|---|
| 0-24h | 25% of applications (7-day listings) | Wave |
| 24-48h | 23% of applications | Wave |
| Week 1 vs later weeks | 2-2.5x | Ashby |
| 0-96h | Up to 8x interview odds | TalentWorks |
| Each day after 96h | -28% | TalentWorks |

What each number can and cannot carry:

- **Wave** is a UK provider, and its figures cover 7-day listings. Adding its two windows gives about 48% of applications inside 48 hours; that sum is mine. No published source gives a 96-hour share, so do not quote one.
- **Ashby** based its week-one finding on 13 million applications. It also found weekly application rates rose 3x over the period it studied, so pools are growing as well as filling early.
- **TalentWorks** reports that applying in the first 96 hours makes you up to 8x more likely to get an interview, that each day after that cuts your chances by 28%, and that it is "nearly not worth applying after 10 days". The time-of-day study used 1,610 applications. One site cites "over 160,000", which conflicts with the other reports.
- **Secondary citations only:** a Greenhouse benchmark is reported at 244 applications per posting in North America, up 111%. An older StartWire study found that applicants from a job's first two days filled more than a quarter of jobs, and first-week applicants filled half.

The sources disagree on the best moment:

- Much common advice says 24 to 48 hours.
- One TalentWorks summary says applications sent 2 to 4 days after posting have the highest chance.
- Another TalentWorks summary says first-24-hour odds were roughly six times higher than waiting even four days.

Here is how I resolve it. All three place the drop somewhere between day 4 and day 10, and none says later is better. So 96 hours of true age is the outer edge of fresh, not the target. Aim for the first 48 hours whenever the source date allows it.

> A repost resets the board's counter. It does not reset the pile of applications already waiting.

So is it too late to apply to a job posted two weeks ago? If the source date confirms two weeks, the listing sits in the late window. It is still winnable, but a cold application lands on a pile that has mostly been read. That is why the late window goes through a person first.

## The four true-age windows and the action each one gets

Sort every row into one of four windows and give each window its own action:

- **Fresh:** 0-96 hours of true age
- **Active:** 4-10 days
- **Late:** 10-30 days
- **Stale-repost:** over 30 days, or any repost flag

I derived these cut-offs from the TalentWorks 96-hour and 10-day thresholds plus Ashby's week-one peak. They are not a published standard.

| Window | True age | Action | Send by |
|---|---|---|---|
| Fresh | 0-96 hours | Fast send | Source date + 96h |
| Active | 4-10 days | Tailored send | Today |
| Late | 10-30 days | Referral-first | Contact made, or reason logged |
| Stale-repost | 30+ days or flagged | Ghost-Job Read | Only if it passes |

What each action means in practice:

- **Fast send.** Submit a tailored resume and a short letter without polishing them for days. A lost day costs more than a slightly plainer letter. Tailoring is usually the bottleneck here, and it is where [Refolk](/candidates) helps: it builds a resume tailored to each posting from your own history and drafts the cover letter, so a fresh row takes minutes rather than an evening.
- **Tailored send.** You still have time, but not much. Spend it on the roles you actually fit, and go deeper on the resume and letter for each one.
- **Referral-first.** Before applying cold, find a person at the employer: a recruiter, the likely hiring manager, or a former colleague. Then send the application alongside that contact. If no contact turns up by a deadline you set, send cold and log the reason.
- **Ghost-Job Read.** This is a separate check on whether the listing is a live opening at all. Do no tailoring until the listing passes it.

#### Window call when age and repost evidence disagree

Horizontal axis runs from Young true age to Old true age. Vertical axis runs from No repost evidence to Strong repost evidence.

| Quadrant | What it means |
| --- | --- |
| Recycled, looks fresh | Search your log and a cached copy; if the req ID appeared before, date it from that sighting |
| Stale repost | Send to the Ghost-Job Read before any tailoring |
| Genuinely fresh | Fast send before the source date plus 96 hours |
| Long-open, no repost | Check for PERM, evergreen, or several posts on one job before going referral-first |

*A young date with repost evidence is the trap; the first-seen log decides it, not the board.*

### Exceptions that override the window

- **PERM ads.** PERM labor certification is the US process an employer completes before sponsoring a foreign worker for a green card. Its recruitment includes a 30-day job order with the State Workforce Agency (SWA). It also requires a Notice of Filing posted for 10 consecutive business days. All of this happens 30 to 180 days before filing. The notice exists to inform employees and is "not another way to recruit U.S. workers". The giveaways are a 30-day run, worksite notice language, and an unusually specific list of requirements. Whether such a role is open to outside applicants is not established. Do not spend fresh-window effort on it. The governing rule is 20 CFR 656.17, which you can read on eCFR.
- **Several posts on one job.** Greenhouse gives each post its own `id` and gives the underlying job an `internal_job_id`, so several posts can map to one job. A "new" post may be an added location on an old job. Compare `internal_job_id` before you call it fresh.
- **Evergreen requisitions.** Workday evergreen requisitions can stay open to collect candidates for recurring or hard-to-fill roles. Their age tells you nothing. Treat them as active: send tailored, without first-batch urgency.
- **Reopened after a failed shortlist.** The only evidence for this pattern is anecdotal; it is not established publicly. If you suspect it, referral-first is the only way to find out.

## The daily true-age run, step by step

The run has seven steps, done every morning in this order. Tracing a listing to its source date (steps 2 and 3) takes under two minutes. The send deadline for each fresh row is its source date plus 96 hours, not the time you found it.

#### The true-age run

1. **Capture the queue** - Record every board URL, the age the board displays, and any "Reposted" label. About 10 minutes; done when there is one row per listing.
2. **Resolve each listing to its ATS** - Click through to the careers page and identify the host: boards.greenhouse.io or gh_jid, jobs.lever.co, jobs.ashbyhq.com, or myworkdayjobs.com. Under a minute each; done when the host and req ID are logged.
3. **Pull the source date** - Read first_published (Greenhouse), createdAt (Lever), publishedAt (Ashby), or startDate / datePosted (Workday detail page). About a minute; done when the row has an ISO date.
4. **Cross-check for a repost** - Compare the board date with the source date and the req ID with your earlier captures and a cached copy, and flag gaps near 30 or 60 days. Done when each row is tagged repost Y or N.
5. **Assign a window** - Mark each row fresh (0-96h), active (4-10 days), late (10-30 days), or stale-repost (over 30 days or flagged). About 5 minutes for the queue.
6. **Choose the action** - Fast send, tailored send, referral-first, or Ghost-Job Read, after checking for PERM, several posts on one job, and evergreen exceptions.
7. **Send and log** - Send every fresh row before its source date plus 96 hours, and the active rows today. Done when every late or skipped row has a reason code.

Notes on the steps that trip people up:

- **Step 2.** If the careers page is a custom front end, look at where the "Apply" button goes. The ATS host usually appears in that URL.
- **Step 3.** Write every date in one format (year-month-day, plus a time where the feed gives one). Mixed formats break the window sort.
- **Step 4.** If the gap between the source date and the board date lands close to 30 or 60 days, an automated renewal is the likely cause. That pattern is a heuristic from secondary sources, not a documented rule.
- **Step 6.** If you have more active rows than you can tailor in a day, rank them by fit, not by age. Refolk's fit score gives you that ranking without rereading every posting.

**True-age queue log (one row per listing)**

```
date_seen,board,board_url,board_age_text,repost_label,ats_host,req_id,internal_job_id,source_field,source_date_iso,first_seen_by_me,repost_flag,window,action,send_deadline,sent_at,reason_code
```

*Paste into a spreadsheet as the header row; keep every past row, because old rows are your repost detector.*

> **Tip:** Send in the company's morning
>
> TalentWorks found applications sent between 6 and 10am got interviews about 13% of the time, falling below 3% after 7:30pm. Those hours are in the company's time zone, and the finding is directional.

## How the true-age run goes wrong

Most errors come from trusting a field that looks like a date but measures something else. For each failure mode below: what you see, why it misleads, and the check that catches it.

### Ashby rows look fresh when they are not

- **What you see:** a recent `publishedAt` on a role you vaguely remember.
- **Why it lies:** Ashby defines the field as last published, so any republish makes an old req look new.
- **Check:** search your earlier captures and a cached copy for the req ID or title. If either turns it up, date the row from the earliest sighting and flag it as a repost.

### Greenhouse `updated_at` used as the post date

- **What you see:** a list of jobs sorted newest first, many sharing a timestamp.
- **Why it lies:** `updated_at` is a maintenance stamp. One board showed 29 distinct values across 232 postings, which is what bulk edits produce. Ashby, by contrast, showed 814 distinct values for 814 postings. Any tool that sorts Greenhouse jobs by `updated_at` gets their dates wrong.
- **Check:** use `first_published` only.

### Workday "30+" treated as a date

- **What you see:** "Posted 30+ Days Ago", logged as day 30.
- **Why it lies:** the label is a lower bound, not a date. The job might be 31 days old or 300.
- **Check:** open the detail record and read `startDate`, or search the page source for `datePosted`.

**59% - Share of listings on one NVIDIA Workday snapshot showing "Posted 30+ Days Ago"**

That was 1,601 listings with no usable date in the list view, which is why the detail-page step cannot be skipped on large Workday sites.

### The board date belongs to a late copy

- **What you see:** "1 day ago" on LinkedIn for a role that has been on the careers page for a week.
- **Why it lies:** if an integration or a recruiter added the job to the board late, the board's clock starts then.
- **Check:** the careers-page or ATS date always wins over the board date.

### A new post sits on an old job

- **What you see:** a Greenhouse post with a recent `first_published`.
- **Why it lies:** several posts, often one per location, can share one `internal_job_id`. The post is new, but the job and its pile of applicants may not be.
- **Check:** compare `internal_job_id` against your log. A match on an older row means you date the job from the older row.

### PERM ads read as stale real jobs

- **What you see:** a long-open listing with oddly narrow requirements.
- **Why it misleads:** it may be a compliance step with a fixed 30-day run, not a role recruiting in the normal way. It is not necessarily a ghost job either.
- **Check:** look for the 30-day run, worksite notice language, and the narrow requirement list. Log it as PERM-likely, and note that whether outside applicants are considered is not established.

### TalentWorks treated as precise

- **What you see:** "8x" and "28% per day" quoted as fact.
- **Why it misleads:** the figures trace to an older sample of about 1,600 applications that is sometimes mis-cited as 160,000, and I could not retrieve the primary page.
- **Check:** use the figures to set the order of the work, not to forecast your odds.

### Time zone drift

- **What you see:** an application sent at 8am your time, which is evening for the employer.
- **Why it misleads:** the TalentWorks hours refer to the company's time zone, not the applicant's.
- **Check:** add the employer's time zone to the row and schedule the send for their morning.

## Keeping the run accurate from one day to the next

Your first-seen log is the real asset. It gets more useful every day, because it is the only repost check that works the same way on every ATS. Keep every row, log a reason for every row you did not fast-send, and recheck the field definitions from time to time, because vendors can change them.

For logging, a reason code turns a vague "didn't get to it" into something you can audit at the end of the week. Use a fixed set so the codes can be counted:

**Reason codes for late and skipped rows**

```
LATE-REF     Late window, waiting on a referral contact (deadline set)
LATE-COLD    Late window, sent cold after no contact by deadline
STALE-GJR    Stale-repost, sent to the Ghost-Job Read
REPOST-SEEN  Req ID or internal_job_id matched an earlier row
PERM-LIKELY  30-day run, notice language, narrow requirements
EVERGREEN    Evergreen requisition, sent as active without urgency
NO-DATE      No source date found (no ATS feed, no JSON-LD, no cache)
FIT-SKIP     Fresh or active, skipped for low fit
MISSED-96H   Fresh row not sent before source date plus 96 hours
```

*Put one code in the reason_code column for every row that was not fast-sent; add a few words after the code if needed.*

To keep the method current, recheck how each system works instead of trusting what this guide says today:

- **Field meanings.** Every few months, reread the Greenhouse Job Board API and Ashby Job Postings API documentation for the date fields. If Greenhouse ever documents whether a repost changes `first_published`, update your Table B row.
- **Workday dates.** When you see a Workday listing again after a repost, note whether `startDate` changed. A handful of your own observations beats the current "not established".
- **Auto-renewal.** Count how many of your REPOST-SEEN rows show gaps near 30 or 60 days. If the pattern holds in your own market, treat those gaps as confirmed renewals there.
- **Your own misses.** If MISSED-96H shows up more than once a week, the queue is too big for the run. Narrow your alert queries rather than shortening the trace.

#### Before you close the day's run

- [ ] Every row has an ATS host and a req ID, or the NO-DATE code
- [ ] Every source date came from first_published, createdAt, publishedAt, startDate, or datePosted, never updated_at or a "30+" label
- [ ] Every Ashby row was checked against earlier captures or a cached copy
- [ ] Every Greenhouse row was checked for a shared internal_job_id
- [ ] Every row is tagged repost Y or N and sits in exactly one window
- [ ] Every fresh row was sent before its source date plus 96 hours, in the company's morning
- [ ] Every late, stale, or skipped row has a reason code
- [ ] Today's rows are kept in the log for tomorrow's repost check

## Frequently asked questions

### How do I find the original posting date of a job?

Follow the listing back to the employer's careers page, work out which applicant-tracking system hosts it, and read that system's date field. On Greenhouse that is first_published, on Lever createdAt, on Ashby publishedAt (which means last published), and on Workday the startDate or datePosted in the job's detail page. Then compare the req ID with your own earlier captures and a cached copy, because a repost can move some of these dates.

### What does Reposted mean on a LinkedIn job?

It means the listing was posted again. That says nothing about whether the role is new. A secondary summary of LinkedIn's help pages says renewing a promoted job changes its posting date, and employers can repost a closed job as a new posting while earlier applicants stay reachable through the closed post. So the employer may already hold a full pile of candidates. Find the source date before you treat a reposted listing as fresh.

### How soon should I apply after a job is posted?

Apply within 96 hours of the job's true first-published date, and inside 48 hours if you can. One UK provider found about 48% of applications on 7-day listings came in during the first 48 hours. Ashby found a posting's first week draws 2-2.5x the volume of later weeks. TalentWorks figures point the same way, but treat them as directional because the primary source was not available to check.

### Is it too late to apply to a job posted two weeks ago?

It is not too late, but if the true age really is two weeks the listing is in the late window, and a cold application joins a pile that is mostly already reviewed. Check the source date first, because the posting may be newer or older than the board says. If it is truly 10 to 30 days old, find a person at the employer before applying, and log why if you send cold anyway.

### How do I check the real posting date on a company careers page?

Look at the careers page URL to identify the system behind it, then read that system's public data. Greenhouse, Lever, and Ashby each have a public job feed that returns a date field for every posting. Workday pages carry a machine-readable JobPosting block in the page source. Search the source for datePosted, or open the detail record and read startDate.

### Why does a Workday job say Posted 30+ Days Ago?

Workday career sites collapse every listing older than 30 days into that label. It is a lower bound, not a date. On one snapshot of NVIDIA's Workday site, 59% of listings carried it. To get the real date, open the job's detail page and read startDate in the detail record, or datePosted in the page source. Whether a Workday repost resets those values is not established.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/candidates/guides/true-age-application-run*