OptiSigns Status

How we measure

This page describes exactly how the figures on our status page are produced, so that they can be checked rather than taken on trust. It is generated from the live monitoring configuration, not written by hand.

What "operational" means

A service is shown as operational when our monitoring reached it and it returned the expected response. It is shown as partial outage or major outage when it did not, and that failure was confirmed across consecutive checks.

Response time does not change a service's status. A service that answers correctly but slowly is shown as operational, and its response time is published as a chart instead. We hold ourselves to much tighter response-time targets internally, and we alert our engineers on them, but those targets are early warnings for us rather than statements about whether the service works for you. The one exception is a request that has not been answered at all after the limit in the table below — that is treated as unavailability, because at that point it is not an answer.

Degraded performance is declared by an OptiSigns engineer, never by an automated threshold. It means a person has determined that customers are affected in a way our automated checks cannot see.

How availability is calculated

availability = 1 − (counted seconds of outage) / (seconds observed)

Window. One complete calendar month, in UTC. We do not publish a month-to-date figure.
What counts. Only partial outages and major outages. Scheduled maintenance and declared degraded performance do not subtract, which is the common industry convention.
Minimum duration. A single interruption shorter than 60 seconds is not counted toward the figure. It is still shown on the 90-day bar, and the count of any such interruptions is shown next to the figure itself. This follows the same rule Google Cloud applies to its Compute Engine SLA.
Denominator. Seconds we actually observed — not the length of the month. If our own monitoring was down, that time is excluded rather than assumed healthy.
Rounding. Truncated, never rounded up. 99.9949% is published as 99.99%, and never as 100%.
When we publish nothing. If we observed less than 95% of a month, we publish no figure for it and say so. A percentage computed from partial observation is a different claim, not a smaller one.

What we check, and how often

Monitoring runs from sfo3. Checks run every 30, 60, 300 seconds depending on the surface.

Check	Service	Interval	Timeout	Treated as unavailable after
app-metas-i18n	Player Services	60s	10s	8000 ms
player-rest-v5	Player Services	30s	10s	8000 ms
signage-cdn	Player Services	60s	10s	8000 ms
portal-app	Portal	30s	10s	8000 ms
portal-graphql	Portal	30s	10s	8000 ms
mdm-api	Device Management	60s	10s	8000 ms
securelink-us	Device Management	60s	10s	8000 ms
transforge	Asset Processing	60s	10s	8000 ms
designer-api	Designer	60s	10s	8000 ms
designer-app	Designer	60s	10s	8000 ms
hawkbit-ddi	Firmware OTA	300s	15s	12000 ms

How we avoid false alarms

A single failed check never changes what this page shows. A failure must repeat consecutively before it is published, and how many times depends on how strong the evidence is:

What we saw	Consecutive failures before publishing
assertion	3
connection	3
http_4xx	2
http_5xx	2
slow	3
timeout	3

Recovery is deliberately slower than failure: a service must pass 2 consecutive checks before it is shown as operational again. A service that is flapping is still broken.

Response time

We record the median and 95th-percentile response time of every check, every day. We hold ourselves to targets far tighter than anything a person would notice — typically a few hundred milliseconds — and our engineers are alerted when those are missed.

Those targets are not published as a service status, and missing one is not an outage. A page that turned amber whenever an internal early-warning threshold was crossed would be reporting our alerting, not your experience. If slow responses ever do reach the point of affecting customers, an engineer declares an incident and it appears on the status page like any other.

What this page cannot tell you

Monitoring runs from a single region. An issue affecting only a particular network, region or customer may not appear here.
Checks run at an interval, so a very short interruption may fall entirely between two checks.
Availability is measured against our own monitoring, not against your traffic. If your experience differs from what this page shows, your experience is the one that matters — please contact support.

What this page is not

This page is published to help customers understand and respond to incidents. It is not a determination of Service Level attainment or of eligibility for service credits. Those are governed by the Service Level Agreement, under which credits are requested by the customer and confirmed by OptiSigns.