Status
What is answering right now, what nothing is watching, and the reliability numbers this system can actually compute. Four of eleven dependencies are probed; the other seven are listed with the reason why not, because a page that shows only what it watches is telling you about itself.
Probed 2026-10-05 18:21 UTC · not cached, reload for a fresh reading · proof · security
Everything probed is answering.
This page answering at all is itself the signal that the application is serving: it runs on the same deployment as everything else. So the summary above is about the things it depends on, not about whether the site is up — if the site were down you would not be reading this.
Not checked is a state, and it is not a quiet way of saying fine. 7 of 11 dependencies are not probed, each for a stated reason, and several of those reasons are better than a probe would be. Probing ten third parties on every load would also turn one page view into ten requests against providers that — in the case that matters — are already struggling.
A probe that answers within 1500ms is answering; slower than that and it is slow; nothing within 4000ms and it is not answering. Machines should read /api/health, which is the same module behind this page. Refresh no faster than every 30 seconds: that endpoint is rate limited harder than any other, for the reason above.
Dependencies
If it stops: Everything that is not a static page: signing in, every gate decision, every community.
If it stops: Gate decisions on Solana. A holder is told the check could not be made, not that they do not qualify.
If it stops: Gate decisions on Ethereum. Same honest refusal as Solana.
If it stops: Gate decisions on Base. Same honest refusal as Solana.
If it stops: Signing in, and therefore every signed-in surface.
Why nothing probes it: A meaningful probe means an authenticated API call, so the probe itself needs a credential and a budget. The failure is also the most visible one in the system — nobody can sign in — so a dot on a page adds nothing to how fast it is noticed.
If it stops: Nothing a visitor sees. Errors stop being reported, which means the next outage is noticed later.
Why nothing probes it: Sending a synthetic error to check that error reporting works would pollute the data it exists to collect. This is checked by looking at whether anything arrived, not by a probe.
If it stops: New image uploads. Images already on IPFS keep resolving through any gateway.
Why nothing probes it: Not on the critical path, and a probe would be one more third-party request on every health check. An upload failure is reported to the person uploading, immediately.
If it stops: Prices and market figures beside a token. No gate decision depends on them.
Why nothing probes it: Cosmetic. A missing price renders as missing rather than as zero.
If it stops: Starting a new token launch. A launch already confirmed on-chain is unaffected.
Why nothing probes it: The failure is reported to the one person attempting a launch, and a probe cannot distinguish a provider outage from a Solana congestion event.
If it stops: The optional Fund link, which opens MoonPay with a wallet address. Nothing in this system calls it.
Why nothing probes it: It is an outbound link in a page, not a service this server talks to. There is no request to probe, and a broken link is visible to the one person who follows it.
If it stops: All of it.
Why nothing probes it: This endpoint runs on it. A probe that can answer proves it is up, and a probe that cannot cannot answer — so the state is carried by whether this response arrived at all.
Reliability over 30 days
A gate decision comes out three ways — allow, deny, or we could not find out — and the first indicator counts the first two together. A denial is a correct answer. What a holder cannot tolerate is being told nobody found out, so that is the thing being measured.
These counters started at zero on the day they shipped. A window with nothing in it reads as not measured rather than as perfect, which is the difference between a measurement and a decoration.
- Decisions that reached an answer
- Not measured
no gate decisions were recorded in this window, so there is no fraction to state.
- Answered within 2000ms
- Not measured
no decisions reached an answer in this window, so nothing was timed.
- Decisions that ended in an unknown
- Not measured
no gate decisions were recorded in this window, so there is no fraction to state.
- Communities waiting to be removed
- 5communities
Deletion is on request rather than on a schedule, so this is a queue for a person, not a failing job.
Source: gates, status deleted with deleted_at older than the window
The unknown rate is an upper bound on node-provider failure rather than a measurement of it: an unknown also covers a gate rule this system cannot evaluate. One provider per chain with no cross-check is the largest known weakness here, and that number is the one that would move first.
What is not measured, and what would measure it
Two of the six indicators cannot be computed today. They are listed because an indicator nobody can compute is worth knowing about, and because “we measure that” is a claim like any other.
The fraction of attempted community publishes that completed, over 30 days.
Why it matters: A creator who cannot publish has no reason to come back, and nothing currently distinguishes a creator who gave up from one who never started.
What would measure it: An event at the START of activation as well as at the end. The analytics table has the completion; a failed or abandoned attempt leaves no row, so the denominator does not exist.
The fraction of sign-in attempts that produced a session, over 30 days.
Why it matters: Privy is the single largest third-party dependency here, and its failure is the one that takes every signed-in surface with it.
What would measure it: Privy holds the identity, so a failure that happens inside their flow never reaches this server. Measuring it means either their reporting, or a client-side event on a failed callback — which would be a measurement of the browser's opinion, and worth having only if labelled as one.
Known weaknesses of this page
There is no history. Every figure is read at the moment you load the page, and nothing here records what it said an hour ago. So this can tell you what is happening and not what happened, which means it is no use for the question people most want answered after an incident. Recording it needs somewhere to keep it, and inventing a graph from a single reading would be worse than admitting the gap.
No independent vantage point. These probes run inside the same deployment they are reporting on. That is enough to tell you a provider is refusing us, and no use at all for the failure where the whole deployment is unreachable — in which case this page is unreachable too. A credible status page is hosted somewhere else, and this one is not.
Nothing alerts. These numbers can be read; nobody is paged when they move. The data exists to look at, which is the half that was missing before, and looking is still a person deciding to look.
The counters have to agree with each other. A gate decision increments a total and one of three outcome counters in the same block, so they must match. If they do not, this says so rather than publishing a ratio built on the difference:
nothing has been counted yet.
If something here looks wrong, or looks right when it should not, write to hello@totym.io. Quote the x-request-id header from the response if you have one — every refusal this system sends carries one, and it is how a report becomes findable.