A high success rate over the last 30 days cannot tell you whether a service is working now if the latest check is old. An HTTP 200 response also needs a separate check: did it contain the page we expected?
KamuiDash publishes scheduled functional checks as SLIs (service-level indicators) on its status page. Our personal plan does not include an SLA, but we make the observed results and their measurement conditions available.
This article explains what counts as a success, how we handle missing measurements, and how we avoid continuing to show an old result as “healthy.”
First, what does the number measure?
The published application results come from a reference application running on one instance and the dashboard sign-in page running on two instances. They are not an aggregate success rate for every customer application or request.
We check other features using predefined monitoring operations. A running server does not make storage usable if it cannot save a file.
| Target | What we check |
|---|---|
| Public application pages | HTTP responses and expected content |
| Storage | File writes, reads, and deletes |
| Database | Connections, writes, reads, and deletes |
| Dashboard API | Retrieving project information |
These scheduled functional checks are called synthetic monitoring. They let us check a service under defined conditions even when customer traffic is low.
We request the public application pages every minute. Success requires HTTP 200 and the expected response content within 10 seconds. A status code alone could miss a response containing the wrong page.
A cached page cannot establish that the application can respond at that moment. Monitoring requests include cache-bypass settings, and responses identified as cached through response headers are excluded from valid measurements.
The sign-in page check does not include the login transaction. The one-instance and two-instance configurations also monitor different applications; this is not an experiment isolating the effect of instance count.
The same 99.0% can cover different amounts of data
The success rate is the share of valid checks that succeeded.
÷ valid checks × 100
We distinguish failures from missing measurements. An observed response error or timeout is a failure. If there is no usable result—for example, a monitoring task did not run, or a cached response was excluded—the measurement is missing.
The following examples both schedule 1,000 checks. Example A has results for all of them; example B has 100 missing measurements.
| Check breakdown | Example A | Example B |
|---|---|---|
| Scheduled checks | 1,000 | 1,000 |
| Successes | 990 | 891 |
| Failures | 10 | 9 |
| Missing | 0 | 100 |
| Valid checks | 1,000 | 900 |
| Success rate (SLI) | 99.0% | 99.0% |
Missing measurements are excluded from both the numerator and denominator. Both 990 ÷ 1,000 and 891 ÷ 900 equal 99.0%, but example B tells us nothing about the other 100 checks. The daily details therefore show valid and expected check counts as well. We do not fill unobserved periods with healthy results.
For a service with multiple operations, we display the lowest operation success rate. If writes succeed 99% of the time while reads and deletes succeed 100% of the time, the displayed value is 99%. A large number of successful reads cannot dilute a problem with writes.
A note on terminology: An SLI is an observed result; an SLO is an operational target. The measurements and targets on the status page do not constitute an SLA, a service-level agreement.
A “healthy” result has an expiration time
Historical success rates and current availability are different information. If the last check is old, past healthy results alone cannot establish the current state.
For application HTTP checks, the current state becomes “unknown” when the latest result is more than three minutes old.
available?
within three minutes?
We also stop preserving the previous healthy display if status data cannot be retrieved. “Unknown” does not assert that an outage occurred; it means there is not enough evidence to determine the current state.
Historical success rates and the last known check time remain available. Separating current state from historical results lets us display what has actually been confirmed.
Measurement and incident reports serve different roles
An automated check tells us whether an operation met its defined conditions. An operator records the cause, scope of impact, and response, providing context alongside the numbers.
pageMeasurements and context
To keep a place to check the situation when applications have a problem, we serve the public status page separately from the application runtime. Alongside HTTP checks of public pages, database operations run on the service side and send their results to the monitoring side.
Scroll horizontally to explore the upper part of this diagram.
HTTP checksCheck responses and content
Success rates, daily history
Dashboard APICheck each feature
connect, write, read, delete
Measurements run on a schedule, independently of page views. For application HTTP monitoring, the combination of the target and its one-minute measurement slot uniquely identifies a record, so rerunning a task does not count a result twice.
What to check on the status page
Read these three pieces of information together on the KamuiDash status page.
- Success rate and reporting period
Applications cover the last 30 days. Other services cover 30 calendar days including today. Where a service has multiple operations, we display the lowest operation success rate.
- Current state and last check time
Separately from the historical success rate, you can see when the result used to determine the current state was obtained.
- Daily history and incident reports
Daily details show valid and expected check counts. When an incident or maintenance report is present, read it for the impact and response timeline.
One-minute sampling can miss short interruptions between checks. The success rate describes scheduled checks; it does not give an exact count of downtime seconds.
Alongside the success rate, we show what was measured and how recently it was confirmed. Those conditions are part of how we make KamuiDash’s availability visible.