What “as of” means on every page — and why a page loading proves nothing
The date is the most important number on the page. Everything else is only true relative to it.
Every data page on StockLearn carries a date. The scanner header shows a scan date; each mutual fund page shows an as of line; the F&O pages state which session's bhavcopy they were built from. Those dates are not decoration. They are the single most important number on the page, because everything else is only true relative to them.
This piece explains where the date comes from, why a page can legitimately be older than you expect, and one non-obvious failure mode we learned the hard way: a successful page load does not prove the data behind it exists.
Where the date comes from
The stock side runs on NSE end-of-day bhavcopy files, published after the session closes. Our pipeline downloads them in the evening, recomputes every derived measure, and stamps the result with that session's date. The mutual fund side works the same way against AMFI's daily NAV publication, which posts overnight for domestic funds and around midday for international ones.
So the date on a page is the data date, not the date you happen to be reading it. A page viewed on Sunday will show Friday's session. That's correct behaviour, not staleness.
When a page is legitimately older than you expect
Several ordinary situations produce a date that lags:
- Weekends and holidays. No session, no new data. Indian markets have a lot of holidays, and a Diwali-week page can sit several days back quite correctly.
- Late-posting international fund NAVs. Funds with overseas exposure publish later than domestic ones, which is why the MF pipeline runs twice daily rather than once.
- A missed pipeline run. The jobs run on a scheduled machine. If it was off or asleep, that session gets skipped until a later run catches up.
The first two are normal. The third is a real gap, and it's why the date is displayed prominently rather than buried — so you can tell the difference yourself instead of trusting that the page is current because it loaded.
The failure mode that fooled us
In July 2026 a deployment script ran with its exclusion rules broken by a stray whitespace character. The effect was that a synchronise-and-delete operation removed a large set of published data files that weren't part of that particular deployment.
The instructive part isn't the mistake — it's how it hid. Checking the affected URLs returned a perfectly normal success response, with real-looking data. The content delivery network in front of the storage was still serving cached copies of files that no longer existed behind it. Every surface check passed. The files were gone.
The lesson, generalised
A cached response can outlive the thing it's a copy of. For any public file, checking the page is not the same as checking the file — you have to query the origin directly. We now verify against storage rather than against the delivered page, and we treat a clean load as weak evidence.
Why we don't hide the date behind “live”
It would be easy to write "live data" on every page and let readers assume. Plenty of sites do. We don't, for the same reason we don't claim intraday capability we lack: the pipeline is end-of-day, and a page that implies otherwise is making a promise the data can't keep.
The only genuinely live element on the site is the index ribbon on the homepage, which pulls a separate feed refreshed through the day. Everything else is end-of-day and dated.
How to check for yourself
The date in the page header is the first check and covers most cases. If you want to be certain the underlying data moved rather than just the page rendering, compare the scan date across two different pages — they're built in the same pass and should agree. A stock page showing one date and the dashboard showing another means something didn't complete.
If you see that, it's worth telling us. Internal monitoring catches most missed runs, but the combination that slips through is exactly the one above: a partial failure where some outputs updated and others didn't, with every page still loading normally.
Dates on the mutual fund side
Fund pages carry the AMFI NAV date, and the expense ratio and fund size fields carry their own separate vintages — expense ratios update monthly, fund size quarterly. A fund page can therefore show yesterday's NAV alongside a fund size from the previous quarter, and both are current for what they are. Where the underlying disclosure is quarterly, we show the quarter.
Key takeaways
- The date shown is the data date, not the reading date — a Sunday view correctly shows Friday.
- Weekends, holidays and late international NAVs all produce a legitimately lagging date.
- A cached response can outlive the file it copies: a clean page load is weak evidence the data exists.
- We verify against origin storage rather than the delivered page.
- Fund pages mix vintages by design — daily NAV, monthly expense ratio, quarterly fund size.
See these ideas on real stocks
StockLearn runs this read on ~2,000 NSE stocks every evening. Nifty 50 is free, no login.
Browse today's scan →This guide is educational and explains how StockLearn interprets common technical indicators, using illustrative examples. It is not investment advice or a recommendation to buy or sell any security.