TempoLife › Features › Service status
Service status
Probe results for the website, the food reference and the two public APIs. No checks have been recorded yet, so this page reports no data rather than a green board.
No checks recorded yet. The prober (scripts/cron_site_status.php) has not written a row, so every figure below is unknown. This page will not show a service as healthy on the strength of having no evidence.
Current state
| Probe | Last result | HTTP | Response | Checked |
|---|---|---|---|---|
| Website | no data | — | — | — |
| Food reference | no data | — | — | — |
| Answer API | no data | — | — | — |
| Food API | no data | — | — | — |
Uptime
Uptime is the share of stored checks that passed inside each window. With no stored checks there is no share to report, so every cell below reads no data. It will fill in once the prober runs; the 30-day column needs 30 days of it before it means anything.
| Probe | Uptime 24h | Uptime 7d | Uptime 30d | Mean response 24h |
|---|---|---|---|---|
| Website | no data | no data | no data | — |
| Food reference | no data | no data | no data | — |
| Answer API | no data | no data | no data | — |
| Food API | no data | no data | no data | — |
Response time
Website
The front page. If this is down, nothing else on the site is reachable either. Probed at /.
Not enough stored checks to draw a line yet. Two are the minimum.
Food reference
The public food database — the largest set of pages on the site and the one search engines hit hardest. Probed at /calories.
Not enough stored checks to draw a line yet. Two are the minimum.
Answer API
The grounded question endpoint, checked with a query that must return a real answer rather than a 404. Probed at /api/answer?q=calories+in+banana.
Not enough stored checks to draw a line yet. Two are the minimum.
Food API
The open nutrition API, checked against a food that exists in the baked dataset. Probed at /food-api.php?food=banana.
Not enough stored checks to draw a line yet. Two are the minimum.
How this page is measured
A cron job on the same infrastructure requests each endpoint above with a short timeout, records the HTTP status code and the round-trip time, and writes one row per probe per run. This page reads those rows and does arithmetic on them. There is no third-party monitor behind it and no manual override — nobody can mark a service green by hand.
That has an honest limitation worth stating: the prober runs from one place. It sees what a request from that machine sees. A regional network fault, a DNS problem at your resolver or a broken app release will not appear here, because none of those change what the prober measures. A green board means the endpoints answered, not that everything works for everybody.
Checks older than 90 days are deleted rather than aggregated, so the 30-day window is always computed from real rows and the table never silently changes meaning as data ages out.
Incidents are written by a human. They are not generated from failed probes, because a run of failed checks and an incident are different claims: the first is a measurement, the second is an explanation.
Source: TempoLife probe log (site_status_checks), written by scripts/cron_site_status.php · checked no checks recorded
Frequently asked questions
Why does a probe say "no data"?
Because no row exists for it. That happens before the prober first runs, after a probe is renamed, or if the cron job is not scheduled. It never means "probably fine".
Is 100% uptime real?
It means every stored check inside that window passed. With a five-minute interval a 24-hour window holds about 288 checks, and a failure shorter than the gap between two checks can pass unrecorded. Read the check count next to the percentage.
Does this cover the Android app?
Only the parts of it that talk to these endpoints. A crash in the app, a Play Store problem or a Health Connect permission failure does not show up here.
Where do incidents come from?
They are written by hand, after the fact, and each one says what happened and when it was resolved. An incident that is still open appears at the top of this page.