4 ms·

> "GitHub has had 1125 incidents since February 2016, implying a monthly incident rate of 24" 1125 incidents / 126 months ≈ 8.9 incidents per month, not 24 st

> "GitHub has had 1125 incidents since February 2016, implying a monthly incident rate of 24" 1125 incidents / 126 months ≈ 8.9 incidents per month, not 24 still terrible, but why such an obvious error in the first sentence...

4petesake 1mo ago
Prob used Copilot to write the excel formula...
6LLvveMx2koXfwn 1mo ago
Not sure whether it has been updated since your comment, but the sentence now reads: GitHub has had 1125 incidents since March 2016. Over the last 3 months, they've averaged 24 incidents per month edit: although they also have 1.2 days of downtime (in a day) for their 'worst days' of downtime table, which suggests some auto number crunching is not working as expected.
- gen220 1mo ago
  Yes I tweaked it! The number and copy were mismatched and are no longer! That worst day is likely an overlapping incidents accounting issue; I tried to account for overlapping incidents in another view but probably failed to port it over there. Should be fixed soon!
stevage 1mo ago
> GitHub has had 1125 incidents since March 2016. Over the last 3 months, they've averaged 24 incidents per month (↓ 5% vs prev 3mo). Looks like they fixed it already
graypegg 1mo ago
Ahhh, I think the author mixed up two values here. That value seems to actually be the average over the past 3 months. const incidents = e.detail.incidents; // ...snip... const now = new Date(); const threeMonthsAgo = new Date(now); threeMonthsAgo.setMonth(threeMonthsAgo.getMonth() - 3); // ...snip... var currentFreq = recentIncidents.length / 3; // <- We out here, smoking these guns with our homeboy Claude // ...snip... var earliest = null; for (var j = 0; j < incidents.length; j++) { var dd = new Date(incidents[j].started_at); // <- eventually incidents[j].started_at is "2016-03-01T07:07:37.000Z" if (!earliest || dd < earliest) earliest = dd; } // ...snip... document.getElementById('n-since').textContent = earliest ? earliest.toLocaleDateString('en-US', { month: 'long', year: 'numeric' }) : '?'; document.getElementById('n-rate').textContent = Math.round(currentFreq * 10) / 10; #n-since is going to be either march or feburary. It'll change depending on your timezone because JS's Date object always shifts the date around to match the same instant but in the system's timezone. #n-rate has nothing to do with the #n-since month, it's just the last trailing 3 months. And even then, it's sort of underbaked? It's moving the date back by 3 calendar months not taking into account differing numbers of days, so it'll under-report short months. I wouldn't trust the stats here. Edit: whoops, author updated the template while I was writing this! It now says "Over the last 3 months", though that's still calendar months.

4petesake 1mo ago

Prob used Copilot to write the excel formula...

6LLvveMx2koXfwn 1mo ago

Not sure whether it has been updated since your comment, but the sentence now reads: GitHub has had 1125 incidents since March 2016. Over the last 3 months, they've averaged 24 incidents per month edit: although they also have 1.2 days of downtime (in a day) for their 'worst days' of downtime table, which suggests some auto number crunching is not working as expected.

gen220 1mo ago
Yes I tweaked it! The number and copy were mismatched and are no longer! That worst day is likely an overlapping incidents accounting issue; I tried to account for overlapping incidents in another view but probably failed to port it over there. Should be fixed soon!

stevage 1mo ago

> GitHub has had 1125 incidents since March 2016. Over the last 3 months, they've averaged 24 incidents per month (↓ 5% vs prev 3mo). Looks like they fixed it already

graypegg 1mo ago

Ahhh, I think the author mixed up two values here. That value seems to actually be the average over the past 3 months. const incidents = e.detail.incidents; // ...snip... const now = new Date(); const threeMonthsAgo = new Date(now); threeMonthsAgo.setMonth(threeMonthsAgo.getMonth() - 3); // ...snip... var currentFreq = recentIncidents.length / 3; // <- We out here, smoking these guns with our homeboy Claude // ...snip... var earliest = null; for (var j = 0; j < incidents.length; j++) { var dd = new Date(incidents[j].started_at); // <- eventually incidents[j].started_at is "2016-03-01T07:07:37.000Z" if (!earliest || dd < earliest) earliest = dd; } // ...snip... document.getElementById('n-since').textContent = earliest ? earliest.toLocaleDateString('en-US', { month: 'long', year: 'numeric' }) : '?'; document.getElementById('n-rate').textContent = Math.round(currentFreq * 10) / 10; #n-since is going to be either march or feburary. It'll change depending on your timezone because JS's Date object always shifts the date around to match the same instant but in the system's timezone. #n-rate has nothing to do with the #n-since month, it's just the last trailing 3 months. And even then, it's sort of underbaked? It's moving the date back by 3 calendar months not taking into account differing numbers of days, so it'll under-report short months. I wouldn't trust the stats here. Edit: whoops, author updated the template while I was writing this! It now says "Over the last 3 months", though that's still calendar months.