Aug 4 – 9, 2026: No monitoring data, uptime —, 6 of 7 days fall in this range, View the daysAug 10 – 16, 2026: No monitoring data, uptime —, View the daysAug 17 – 23, 2026: No monitoring data, uptime —, View the daysAug 24 – 30, 2026: No monitoring data, uptime —, View the daysAug 31 – Sep 6, 2026: No monitoring data, uptime —, View the daysSep 7 – 13, 2026: No monitoring data, uptime —, View the daysSep 14 – 20, 2026: No monitoring data, uptime —, View the daysSep 21 – 27, 2026: No monitoring data, uptime —, View the daysSep 28 – Oct 4, 2026: No monitoring data, uptime —, View the daysOct 5 – 11, 2026: No monitoring data, uptime —, View the daysOct 12 – 18, 2026: No monitoring data, uptime —, View the daysOct 19 – 25, 2026: No monitoring data, uptime —, View the daysOct 26 – Nov 1, 2026: Normal, uptime 100.00%, View the days
Oct 26 – Nov 1, 2026
Normal·Uptime 100.00%
Normal days
3
Days without data
4
Maintenance days
3
Incidents
0
Checks
2,673
Use the arrow keys, Home and End to move between periods. Enter opens the days of a week or month; Escape goes back.
Incidents
0
Outage time (incident records)
0 seconds
Data coverage
100.0%since monitoring began on Oct 30, 2026
Monitoring began on Oct 30, 2026. The 87 days before it are shown as “no monitoring data”. Data on 3 of 90 days
Aug 4 – 9, 2026: No monitoring data, uptime —, 6 of 7 days fall in this range, View the daysAug 10 – 16, 2026: No monitoring data, uptime —, View the daysAug 17 – 23, 2026: No monitoring data, uptime —, View the daysAug 24 – 30, 2026: No monitoring data, uptime —, View the daysAug 31 – Sep 6, 2026: No monitoring data, uptime —, View the daysSep 7 – 13, 2026: No monitoring data, uptime —, View the daysSep 14 – 20, 2026: No monitoring data, uptime —, View the daysSep 21 – 27, 2026: No monitoring data, uptime —, View the daysSep 28 – Oct 4, 2026: No monitoring data, uptime —, View the daysOct 5 – 11, 2026: No monitoring data, uptime —, View the daysOct 12 – 18, 2026: No monitoring data, uptime —, View the daysOct 19 – 25, 2026: No monitoring data, uptime —, View the daysOct 26 – Nov 1, 2026: Normal, uptime 100.00%, View the days
Oct 26 – Nov 1, 2026
Normal·Uptime 100.00%
Normal days
3
Days without data
4
Incidents
0
Checks
2,668
Use the arrow keys, Home and End to move between periods. Enter opens the days of a week or month; Escape goes back.
Incidents
0
Outage time (incident records)
0 seconds
Data coverage
100.0%since monitoring began on Oct 30, 2026
Monitoring began on Oct 30, 2026. The 87 days before it are shown as “no monitoring data”. Data on 3 of 90 days
Weekly and monthly uptime is weighted by the actual numbers of successful and total checks, not averaged from daily percentages. A short outage marks its day without colouring the whole week or month.
Uptime comes from every check; outage time comes from incident records (major and critical incidents, excluding planned maintenance). The sources differ, so the two numbers need not match.
One incident can affect several services, so the per-service counts can add up to more than the site-wide total.
Data coverage is the share of expected checks recorded since the service was added to monitoring. Days before that, or without results, are shown as “no monitoring data” and count neither as up nor as down.
Incident trend
Incidents started per week, by severity.
MaintenanceMinorMajorCritical
Use the left and right arrow keys to move between bars.
Data table
Started
Minor
Major
Critical
Maintenance
Aug 4
0
0
0
0
Aug 10
0
0
0
0
Aug 17
0
1
0
0
Aug 24
0
1
0
0
Aug 31
0
4
0
0
Sep 7
0
0
0
0
Sep 14
0
3
0
0
Sep 21
0
3
0
0
Sep 28
0
0
0
0
Oct 5
0
0
0
0
Oct 12
0
9
0
1
Oct 19
0
8
0
3
Oct 26
0
9
0
0
How we measure
Each service is checked every minute from Cloudflare’s network with an HTTP request (8-second timeout, up to two retries 3 seconds apart).
Before an outage is reported, the result is confirmed with a second method (a browser-like HEAD and GET with cache bypass). If either method gets an answer, the service is not reported down.
Responses slower than the service’s threshold (1 second by default) are reported as slow. A failed content check is also reported as slow.
An incident opens automatically after a confirmed outage and closes after five consecutive successful checks. The YUCTS team can also post incidents and updates manually.
Uptime is the share of successful checks. Periods without checks (for example before a service was added) are shown as “no data” and are excluded rather than counted as up.
Availability for the service level objective uses incident durations: overlapping incidents are merged, and planned maintenance windows are excluded from both the downtime and the measured time.
Raw checks are kept for 24 hours and daily summaries for 365 days. All times are stored in UTC.