Site status

What is live on tinycorp.ai, and what the machine itself says about it. Every figure on this page is read when you load it — from the running process, a file’s own timestamp, the gunicorn error log, the dataset manifest, the readers ledger and the route manifest. Nothing here is typed in. A figure that could not be read says not measured rather than a guess.

Read Thursday 24 September 2026, 07:04 UTC · cached for two minutes · the same payload as /api/status.json

answeringyou are reading a page this service just rendered · serving for 74 minutes
19gunicorn worker timeouts in the last 7 days (was 119 the 7 before)
66 / 66required routes still defined in the running code — 0 open
39,512,645rows of price tape archived as downloadable CSV, across 2 months
563 · 327AI-crawler requests in 7 days: verified against a published IP range · claimed only
20.9 GBthe price database, with 25.0 GB free on its volume

What is live

Every row names the file or the process it was read from. Times are UTC — the box’s clock, and the clock every log here is written in.

WhatReadingWhere it comes from
The serviceup · 3 workers · 60s request timeoutthe gunicorn master’s own /proc/1115597/cmdline, read by the worker serving this page
Serving sinceThursday 24 September 2026, 05:49 UTCthe master process start time in /proc, against the kernel’s boot clock — this is when the service last restarted
Last deploy — codeThursday 24 September 2026, 05:49 UTC (75 minutes ago)app.py mtime, 206.8 KB. Every push goes through safe_deploy.sh, which refuses the copy unless the candidate still defines every route the running file does.
Last deploy — templatesThursday 24 September 2026, 05:49 UTCthe newest mtime under templates/templates/quants/status.html
Route guard66 of 66 presentrequired_routes.txt (69 lines, blanks and comments included), each name greped for as ^def name( in the running app.py — the same check safe_restart.sh makes before it will restart anything.
Worker timeouts, last 7 days19WORKER TIMEOUT lines in /var/log/tinycorp-signal-error.log (1.3 MB). A request that times out never reaches the access log, so this file is the only record. Series below.
Price tape — last export2026-08 · 15,719,040 rowsstatic/datasets/manifest.json — written by the export itself, 2026-09-17T05:19:18+00:00, 423 s, 287.6 MB gzipped
Price tape — all months39,512,645 rows · 2 monthsthe same manifest, summed across its month entries. Unit: rows of the tape, not markets and not trades. The tape and its schema →
Checksums2 of 2 filesone .sha256 beside each archive; the newest was written 2026-09-17T05:19:18Z and starts 5d16f485a7259a02…check it yourself
Price database20.9 GB + 2.2 GB write-ahead log/mnt/HC_Volume_106613800/tinycorp/predictive.db, read with stat. This is the live tape the pollers write to; the CSVs above are monthly archives cut from it.
Free space25.0 GB free · 48.9% usedstatvfs on the volume the database sits on (/mnt/HC_Volume_106613800/tinycorp), of 48.9 GB total
Who reads this data563 verified · 327 claimeddata/readers.json, rebuilt nightly from the nginx access log; last built 2026-09-24T01:44:02+00:00. The full ledger →

Worker timeouts, day by day

A worker timeout is gunicorn killing a request that ran past its 60-second ceiling — the reader saw an error. In September the cause was found: the backtester ran a COUNT(*) across the whole 20.9 GB price tape on every run. That was fixed on 2026-09-18. Since that day the log has recorded 9 more. The series below is read straight out of the log — it is not a claim that the fix worked, it is the evidence, and a bad day would show up here the same way the old ones do.

1709-11
1009-12
909-13
2509-14
2309-15
2209-16
1309-17
1009-18
309-19
509-20
109-21
009-22
009-23
009-24

Each box is one UTC day, oldest on the left; the bar is against the worst day shown (25). Last 7 days 19, the 7 before that 119. Lifetime total 403 since 2026-05-27; the last day with one was 2026-09-21.

Who reads us

Requests from clients that name themselves an AI crawler or assistant, over the last 7 days, split by whether the address was inside the IP range that crawler’s operator publishes. Verified means the user-agent said it and the address checks out. Claimed means the user-agent said it and the address was not on the list — anyone can type any user-agent, and most of the claimed rows here are scanners probing for .env files under a famous name. Requests, not visitors, not pageviews.

FamilyVerifiedClaimedTotal
PerplexityBot 184 75 259
ClaudeBot 171 92 263
OAI-SearchBot 119 40 159
ChatGPT-User 69 43 112
GPTBot 20 48 68
Google-Extended 0 29 29
Claude-User 0 0 0
Claude-SearchBot 0 0 0

5 of 14 AI families had at least one verified request in the window 2026-09-11 to 2026-09-24. A further 930 requests came from families whose operator publishes no range at all, so they can be neither verified nor disproved. Every family, every day, and the range lists →

The honest gaps

What this page can see that is missing, incomplete or easy to misread. Derived from the same reads above, not from a list somebody keeps.

What this page does not say

No money
Every bot on tinycorp.ai trades paper. There is no revenue figure, no profit and no sum of anything across bots on this page, because none of those would mean anything here.
No other site’s numbers
This studio runs four sites and each one keeps its own status page. Counts from American Adventurer, Momatio or 223 Hampshire are never printed here, even where the same machine serves them — a number on this page is tinycorp.ai’s own or it is not here.
No visitors
The readers table counts requests in a web-server log. It is not visitors, not pageviews, and a user-agent can be forged — which is exactly what the verified/claimed split is for.
Not a promise
“Up” here means this page rendered. It is a reading taken at the moment you loaded it, cached for two minutes, and it says nothing about the next two.
Read it yourself
The same payload is JSON at /api/status.json, the page is quants/status_page.py, and every source it reads is named in the table above.