What "Posted 3 Days Ago" Actually Means
You want to know two things about a role before you spend an hour on it: is it still genuinely open, and how far ahead of you is everyone else. The listing offers you a date, so you use the date.
It’s a weak proxy, and it’s weak in ways that aren’t obvious from looking at it. Worth knowing exactly how weak, because a lot of people either over-trust it — skipping anything older than a week — or dismiss it entirely, and both cost something.
The date belongs to the record, not to the job
A listing is a record that has been copied between systems, sometimes several times, before it reaches you. Each system stamps it with a date. Which date you’re shown depends on which system you’re reading, and “posted” can mean any of these:
When the employer first published it. The one you actually want. It’s the least likely to be what you’re seeing if you found the role anywhere other than the employer’s own careers page.
When this particular copy was created. A board ingesting a feed dates the record from ingestion. Same vacancy, later date, entirely honest bookkeeping — see one vacancy, many listings for what else changes on the way.
When the advert was last refreshed. Adverts get re-pushed, edited, or bumped. Depending on the system, that can reset the visible date on a role that’s been open for two months.
A rounded label. “3 days ago”, “30+ days ago”, “posted last week”. These are display strings computed from a timestamp, and the rounding hides the thing you’d want — the difference between 31 days and 90 is invisible under “30+”.
There’s also a stale-copy effect layered on top. Cached responses are a normal, deliberate part of how this data gets served and re-served: Serply’s published credit rates charge one credit for a successful uncached request and nothing at all for a cached one, which tells you how routine it is for a consumer of this data to be reading a stored copy rather than a live one. Somewhere between the employer’s system and your screen there are almost certainly several stored copies, each with its own idea of what time it is.
What the date genuinely does tell you
It isn’t useless. Two things survive all that:
Relative freshness within one source. Comparing two listings on the same board is comparing like with like, more or less. Across sources it’s meaningless.
A very old date is a real signal. “30+ days” on a listing that’s still up doesn’t prove the role is stale, but combined with anything else — no reference number, a vague description, an agency you can’t identify — it’s worth being less generous with your hour.
What it does not tell you
Whether the role is still open. Adverts stay up after a hire. They also stay up while a process runs, while a shortlist is being interviewed, and occasionally when nobody has looked at the applications yet.
How many applications are already in. There is no relationship you can rely on between age and volume. A niche role can be up for three weeks with eleven applicants; a broad one can take four hundred in two days.
Whether being early actually helps here. It usually helps — most processes review as applications arrive, so early candidates are read against an emptier field. But some employers open a window, close it, and review everything together, in which case day one and day six are identical.
The date you should actually use is your own
You can’t fix the listing’s date. You can add one that’s fully reliable: first seen, meaning the day it appeared in front of you.
Two fields, both cheap:
First seen 2026-08-03 (the day it hit your feed)
Applied 2026-08-05 (blank until submitted)First seen costs nothing because you’re logging the role at triage anyway, and it earns its place three ways.
It measures your own latency. First seen minus applied, across thirty rows, is the honest answer to “how long do things sit in my queue?” Almost everyone’s number is larger than they think, and it’s one of the few levers you fully control.
It gives you a real age. Not the listing’s claimed age — the number of days since you could have acted. That’s the figure that should trouble you.
It makes reposts visible. A role you first saw on 3 August, reappearing on 2 September with a fresh date, is a repost, and you have the evidence rather than a vague feeling. What to do with that is a separate judgement, covered in never apply to the same job twice.
How much weight to give age at triage
Enough to break ties. Not enough to override fit.
A rough hierarchy for the twenty seconds you spend deciding:
Strong fit, any age → apply
Strong fit, seen today → apply this session, not next week
Moderate fit, fresh → queue it
Moderate fit, 30+ days → queue it last, or bin it
Weak fit, any age → binThe thing to avoid is a rule like “nothing older than seven days”, because it discards roles you’d be genuinely good for on the basis of a number that, as above, may not even describe the vacancy. Age is a tiebreaker between two roles you feel similarly about. It is not a filter.
What age should change is urgency rather than eligibility. A strong match that appeared this morning is the one thing worth reordering your applying block for; everything else can wait for the block you already scheduled.
The failure mode this creates
Here’s the one that costs people weeks. You check the feed, everything is dated a fortnight back, and you conclude the market has gone quiet. So you check less often. So the feed gets staler. So you conclude the market is worse.
Dates going stale in your feed is at least as likely to mean your feed has stopped working — a saved search reset, a filter catching mail, a query that no longer matches how roles are being titled this quarter. It fails silently, which is why the monthly check in set up alerts so roles come to you asks the blunt question: did each of these deliver anything this month?
A quiet market and a broken pipe look identical from inside your inbox. The date on the listing won’t tell you which one you have. Your own first-seen column, with nothing new in it for three weeks, is at least asking the right question.