에이전트 · 자동화원문 · prompts.chat

SLO Error Budget and Burn Rate Calculator

Turns request counts into SLO answers: SLI, error budget for a 28d or 30d window, budget consumed and remaining, burn rates over 5m to 3d, multiwindow burn-rate alerts (page at 14.4x and 6x, ticket at 3x and 1x, scaled to the window), and time until the budget runs out. Use when setting an SLO, tuning alerts, deciding on a release freeze, or writing an incident summary. Includes a stdlib Python…

추천 툴: 코딩 에이전트(스킬)형식 기준 추천
쓰인 기법: 에이전트 스킬(SKILL.md)

프롬프트 원문

---
name: slo-error-budget-burn-rate-calculator
description: Turns request counts into SLO answers: SLI, error budget for a 28d or 30d window, budget consumed and remaining, burn rates over 5m to 3d, multiwindow burn-rate alerts (page at 14.4x and 6x, ticket at 3x and 1x, scaled to the window), and time until the budget runs out. Use when setting an SLO, tuning alerts, deciding on a release freeze, or writing an incident summary. Includes a stdlib Python calculator with --self-test.
---

# SLO Error Budget and Burn Rate Calculator

You help engineers and on-call teams reason about reliability with numbers instead of gut feeling. You turn good/total request counts into an SLI, translate the SLO into an error budget, show how fast the budget is burning in several windows, say which alerts would page or open a ticket, and estimate when the budget runs out at the current pace. You explain every number in plain language so product owners can follow the decision.

## Files in this skill

- `scripts/slo_budget.py` - reads a CSV of request counts per interval and prints SLI, budget consumed and remaining, burn rates, alert states, exhaustion times and the worst interval; `--allowance` prints allowed downtime and alert thresholds for any SLO (Python 3 standard library only)
- `references/slo-math.md` - formulas for SLI, error budget, burn rate, projected consumption, and worked numbers for common targets
- `references/burn-rate-alerting.md` - the multiwindow, multi-burn-rate alert policy, how thresholds scale with the window, and tuning advice
- `templates/slo-status-report.md` - a weekly SLO status or incident budget summary
- `examples/checkout-api-requests.csv` - two days of 15-minute request counts for a checkout API with a small blip and a 2-hour incident at the end

## Workflow

### 1. Define the SLI and SLO
Ask what a "good" event is (status < 500, latency under 300 ms, successful job run), where the counts come from, the target (99%, 99.5%, 99.9%, 99.95%), and the window (rolling 28 or 30 days). Push back on targets the system has never met: show the historical SLI first.

### 2. Get the data
Export good and total (or bad and total) counts per interval, for example 1-minute, 5-minute or 15-minute buckets, as CSV with `timestamp,total,good`. The timestamp marks the start of each interval. Use UTC.

### 3. Run the calculator
```
python3 scripts/slo_budget.py examples/checkout-api-requests.csv --slo 99.9 --window 30d
python3 scripts/slo_budget.py requests.csv --slo 99.5 --window 28d --json > slo.json
python3 scripts/slo_budget.py requests.csv --now 2026-10-19T22:00:00Z
python3 scripts/slo_budget.py --allowance --slo 99.95 --window 30d
python3 scripts/slo_budget.py --self-test
```
Exit code 1 means a page alert is firing or the budget is exhausted; 2 means bad input (missing columns, bad > total, unparseable timestamps).

### 4. Interpret
- Burn rate 1.0 spends exactly the budget over the window; 14.4 for an hour spends 2% of a 30-day budget.
- Budget consumed is projected against the traffic seen so far; with less than a full window of data, say so.
- An alert fires only when both its long and short window exceed the threshold; the short window makes it stop quickly after recovery. See `references/burn-rate-alerting.md`.
- Windows shorter than the data step are rounded up to one step; windows longer than the data are "not evaluable".

### 5. Recommend and report
Tie the numbers to a decision: page now, open a ticket, slow down risky releases while remaining budget is low, or loosen an SLO that is always violated by design. Fill `templates/slo-status-report.md`.

## Example result
For `examples/checkout-api-requests.csv` at 99.9% over 30d: SLI 99.8768%, 8.2% of the budget consumed, 1h burn 26.46 and 5m burn 28.06 so the fast page fires, 6h burn 5.83 just under 6.0, the 3d ticket is not evaluable with two days of data, and at the last hour's pace the budget is gone in about 1d 16h. Exit code 1.

## Rules

- State the SLO, window, data range and any missing intervals with every result.
- Do not mix good-event definitions in one SLI; compute separate SLOs for availability and latency.
- An SLO is a decision tool, not a blame tool: describe impact on users, not on people.
- Do not invent traffic numbers; if counts are missing, ask for them or say which result cannot be computed.
FILE:references/slo-math.md
# SLO Math

## Definitions
- **SLI** (service level indicator) = good events / total events, as a percentage.
- **SLO** (objective) = target SLI over a window, e.g. 99.9% of requests succeed over a rolling 30 days.
- **Error budget** = 1 - SLO = the share of events allowed to fail. 99.9% -> 0.1%.
- **Budget in events** = (1 - SLO) x total events in the window.
- **Error rate** over a window = bad / total in that window.
- **Burn rate** = error rate / (1 - SLO). 1.0 means the budget would be exactly used up at the end of the window.

## Projected consumption with partial data
With D seconds of data and W seconds of SLO window:
- expected requests in window = (requests in data / D) x W
- allowed bad = (1 - SLO) x expected requests
- consumed = bad in data / allowed bad
- time to exhaustion at a recent rate = (allowed bad - bad so far) / (bad per second in that recent window)

## Allowed full downtime
| SLO | per 30 days | per 28 days | per week | per day |
|---|---|---|---|---|
| 99% | 7h 12m | 6h 43m 12s | 1h 40m 48s | 14m 24s |
| 99.5% | 3h 36m | 3h 21m 36s | 50m 24s | 7m 12s |
| 99.9% | 43m 12s | 40m 19s | 10m 5s | 1m 26s |
| 99.95% | 21m 36s | 20m 10s | 5m 2s | 43s |
| 99.99% | 4m 19s | 4m 2s | 1m 0s | 9s |

Request-based SLOs do not care about clock time directly: 10 minutes of 50% errors costs the same as 5 minutes of full downtime at equal traffic, and an outage at 3 a.m. costs less budget than one at peak.

## Worked example
SLO 99.9%, 30d window, 1,000,000 requests per day.
- Budget: 0.001 x 30,000,000 = 30,000 failed requests.
- A 2% error rate for one hour at 41,667 req/h burns 833 failures = 2.8% of the budget, burn rate 20.
- At burn rate 20 the whole budget lasts 30d / 20 = 36 hours.

## Pitfalls
- Counting retries as separate good events hides user-facing failures.
- Very low traffic (night, new region) makes error rates noisy; use a minimum request count or a longer short window.
- Synthetic probes measure the probe, not users; label them separately.
- Changing the SLO mid-window: recompute the whole window with the new target and say so.
FILE:references/burn-rate-alerting.md
# Burn-Rate Alerting

## Default policy (multiwindow, multi-burn-rate)
| Severity | Budget share | Long window | Short window | Burn threshold (30d) | Burn threshold (28d) |
|---|---|---|---|---|---|
| page | 2% | 1h | 5m | 14.4 | 13.44 |
| page | 5% | 6h | 30m | 6.0 | 5.6 |
| ticket | 10% | 1d | 2h | 3.0 | 2.8 |
| ticket | 10% | 3d | 6h | 1.0 | 0.93 |

Threshold = budget share x SLO window / long window. Example: 0.02 x 720h / 1h = 14.4.

## Why two windows
- The **long window** proves the problem is significant (enough budget spent).
- The **short window** (about 1/12 of the long one) proves it is still happening, so the alert resets within minutes after recovery instead of staying red for an hour.
- Fire only when both exceed the threshold.

## Example alert rule (Prometheus style)
```
(
  sum(rate(http_requests_errors_total[1h])) / sum(rate(http_requests_total[1h])) > (14.4 * 0.001)
and
  sum(rate(http_requests_errors_total[5m])) / sum(rate(http_requests_total[5m])) > (14.4 * 0.001)
)
```

## Tuning
- Low-traffic services: require a minimum number of requests in the short window, or page on 6h only.
- Too many pages: check whether the SLO is stricter than users need before raising thresholds.
- Missed incidents: slow burns below 1.0 never alert by design; review the budget weekly.
- Data step coarser than the short window (e.g. 15-minute buckets): the short window becomes one bucket and recovery detection is slower.

## Budget policy ideas
- Over 50% consumed: review risky changes, prefer canaries.
- Over 75%: release freeze for non-fixes, reliability work first.
- Exhausted: postmortem required; freeze until the rolling window recovers.
FILE:templates/slo-status-report.md
# SLO Status - <service> - <period or incident>

**SLI:** <what counts as good>  **SLO:** <target>% over rolling <28d/30d>
**Data:** <start> to <end> UTC, step <interval>, <n> missing intervals
**Calculator:** `slo_budget.py --slo <target> --window <window>` (exit <code>)

## Budget
| Metric | Value |
|---|---|
| SLI in period | |
| Budget consumed | |
| Budget remaining | |
| Allowed full downtime per window | |

## Burn rates
| 5m | 30m | 1h | 2h | 6h | 1d | 3d |
|---|---|---|---|---|---|---|
| | | | | | | |

## Alerts
| Policy | Status | Long / short burn |
|---|---|---|
| page 1h/5m | | |
| page 6h/30m | | |
| ticket 1d/2h | | |
| ticket 3d/6h | | |

## What happened
<worst interval, user impact, cause if known>

## Decision
- [ ] Page / incident open
- [ ] Release policy: <normal / caution / freeze> because <remaining budget>
- [ ] SLO or alert tuning: <change and reason>

## Summary for stakeholders
> <service> met <SLI>% against a <target>% target. <x>% of this window's error budget is used; at the current pace it lasts <time>. Next step: <decision>.
FILE:examples/checkout-api-requests.csv
timestamp,total,good
2026-10-18T00:00:00Z,4757,4755
2026-10-18T00:15:00Z,4525,4523
2026-10-18T00:30:00Z,4313,4311
2026-10-18T00:45:00Z,4122,4120
2026-10-18T01:00:00Z,3951,3949
2026-10-18T01:15:00Z,3803,3801
2026-10-18T01:30:00Z,3678,3676
2026-10-18T01:45:00Z,3577,3576
2026-10-18T02:00:00Z,3500,3498
2026-10-18T02:15:00Z,3448,3446
2026-10-18T02:30:00Z,3421,3419
2026-10-18T02:45:00Z,3019,3018
2026-10-18T03:00:00Z,3044,3043
2026-10-18T03:15:00Z,3093,3092
2026-10-18T03:30:00Z,3169,3168
2026-10-18T03:45:00Z,3270,3268
2026-10-18T04:00:00Z,3396,3394
2026-10-18T04:15:00Z,3547,3545
2026-10-18T04:30:00Z,3722,3720
2026-10-18T04:45:00Z,3921,3919
2026-10-18T05:00:00Z,4143,4141
2026-10-18T05:15:00Z,4388,4386
2026-10-18T05:30:00Z,4253,4251
2026-10-18T05:45:00Z,4539,4537
2026-10-18T06:00:00Z,4845,4843
2026-10-18T06:15:00Z,5168,5166
2026-10-18T06:30:00Z,5509,5507
2026-10-18T06:45:00Z,5865,5863
2026-10-18T07:00:00Z,6236,6234
2026-10-18T07:15:00Z,6619,6616
2026-10-18T07:30:00Z,7013,7009
2026-10-18T07:45:00Z,7418,7414
2026-10-18T08:00:00Z,7831,7827
2026-10-18T08:15:00Z,7850,7847
2026-10-18T08:30:00Z,8274,8271
2026-10-18T08:45:00Z,8702,8699
2026-10-18T09:00:00Z,9132,9127
2026-10-18T09:15:00Z,9561,9556
2026-10-18T09:30:00Z,9989,9984
2026-10-18T09:45:00Z,10413,10408
2026-10-18T10:00:00Z,10832,10827
2026-10-18T10:15:00Z,11245,11240
2026-10-18T10:30:00Z,11650,11645
2026-10-18T10:45:00Z,12044,12038
2026-10-18T11:00:00Z,12028,12022
2026-10-18T11:15:00Z,12398,12392
2026-10-18T11:30:00Z,12754,12748
2026-10-18T11:45:00Z,13095,13089
2026-10-18T12:00:00Z,13418,13412
2026-10-18T12:15:00Z,13724,13719
2026-10-18T12:30:00Z,14010,14003
2026-10-18T12:45:00Z,14275,14268
2026-10-18T13:00:00Z,14520,14513
2026-10-18T13:15:00Z,14742,14735
2026-10-18T13:30:00Z,14941,14934
2026-10-18T13:45:00Z,14716,14710
2026-10-18T14:00:00Z,14867,14861
2026-10-18T14:15:00Z,14993,14985
2026-10-18T14:30:00Z,15094,15086
2026-10-18T14:45:00Z,15170,15163
2026-10-18T15:00:00Z,15220,15213
2026-10-18T15:15:00Z,15244,15237
2026-10-18T15:30:00Z,15242,15236
2026-10-18T15:45:00Z,15215,15209
2026-10-18T16:00:00Z,15163,15155
2026-10-18T16:15:00Z,14686,14679
2026-10-18T16:30:00Z,14585,14578
2026-10-18T16:45:00Z,14460,14453
2026-10-18T17:00:00Z,14312,14306
2026-10-18T17:15:00Z,14141,14135
2026-10-18T17:30:00Z,13950,13866
2026-10-18T17:45:00Z,13738,13656
2026-10-18T18:00:00Z,13506,13499
2026-10-18T18:15:00Z,13257,13251
2026-10-18T18:30:00Z,12990,12984
2026-10-18T18:45:00Z,12708,12702
2026-10-18T19:00:00Z,12012,12007
2026-10-18T19:15:00Z,11702,11697
2026-10-18T19:30:00Z,11382,11376
2026-10-18T19:45:00Z,11051,11045
2026-10-18T20:00:00Z,10712,10707
2026-10-18T20:15:00Z,10367,10362
2026-10-18T20:30:

출처 · prompts.chat 공개 프롬프트 모음 · 작성 Fatih Kadir Akın — CC0(저작권 포기)로 공개된 원문을 그대로 싣습니다. 한국어 정리 · 실행 결과는 아직 없습니다.

‹ 라이브러리로

SLO Error Budget and Burn Rate Calculator

추천 툴

코딩 에이전트(스킬)형식 기준 추천

쓰인 기법

에이전트 스킬(SKILL.md)

--- name: slo-error-budget-burn-rate-calculator description: Turns request counts into SLO answers: SLI, error budget for a 28d or 30d window, budget consumed and remaining, burn rates over 5m to 3d, multiwindow burn-rate alerts (page at 14.4x and 6x, ticket at 3x and 1x, scaled to the window), and time until the budget runs out. Use when setting an SLO, tuning alerts, deciding on a release freeze, or writing an incident summary. Includes a stdlib Python calculator with --self-test. --- # SLO Error Budget and Burn Rate Calculator You help engineers and on-call teams reason about reliability with numbers instead of gut feeling. You turn good/total request counts into an SLI, translate the SLO into an error budget, show how fast the budget is burning in several windows, say which alerts would page or open a ticket, and estimate when the budget runs out at the current pace. You explain every number in plain language so product owners can follow the decision. ## Files in this skill - `scripts/slo_budget.py` - reads a CSV of request counts per interval and prints SLI, budget consumed and remaining, burn rates, alert states, exhaustion times and the worst interval; `--allowance` prints allowed downtime and alert thresholds for any SLO (Python 3 standard library only) - `references/slo-math.md` - formulas for SLI, error budget, burn rate, projected consumption, and worked numbers for common targets - `references/burn-rate-alerting.md` - the multiwindow, multi-burn-rate alert policy, how thresholds scale with the window, and tuning advice - `templates/slo-status-report.md` - a weekly SLO status or incident budget summary - `examples/checkout-api-requests.csv` - two days of 15-minute request counts for a checkout API with a small blip and a 2-hour incident at the end ## Workflow ### 1. Define the SLI and SLO Ask what a "good" event is (status < 500, latency under 300 ms, successful job run), where the counts come from, the target (99%, 99.5%, 99.9%, 99.95%), and the window (rolling 28 or 30 days). Push back on targets the system has never met: show the historical SLI first. ### 2. Get the data Export good and total (or bad and total) counts per interval, for example 1-minute, 5-minute or 15-minute buckets, as CSV with `timestamp,total,good`. The timestamp marks the start of each interval. Use UTC. ### 3. Run the calculator ``` python3 scripts/slo_budget.py examples/checkout-api-requests.csv --slo 99.9 --window 30d python3 scripts/slo_budget.py requests.csv --slo 99.5 --window 28d --json > slo.json python3 scripts/slo_budget.py requests.csv --now 2026-10-19T22:00:00Z python3 scripts/slo_budget.py --allowance --slo 99.95 --window 30d python3 scripts/slo_budget.py --self-test ``` Exit code 1 means a page alert is firing or the budget is exhausted; 2 means bad input (missing columns, bad > total, unparseable timestamps). ### 4. Interpret - Burn rate 1.0 spends exactly the budget over the window; 14.4 for an hour spends 2% of a 30-day budget. - Budget consumed is projected against the traffic seen so far; with less than a full window of data, say so. - An alert fires only when both its long and short window exceed the threshold; the short window makes it stop quickly after recovery. See `references/burn-rate-alerting.md`. - Windows shorter than the data step are rounded up to one step; windows longer than the data are "not evaluable". ### 5. Recommend and report Tie the numbers to a decision: page now, open a ticket, slow down risky releases while remaining budget is low, or loosen an SLO that is always violated by design. Fill `templates/slo-status-report.md`. ## Example result For `examples/checkout-api-requests.csv` at 99.9% over 30d: SLI 99.8768%, 8.2% of the budget consumed, 1h burn 26.46 and 5m burn 28.06 so the fast page fires, 6h burn 5.83 just under 6.0, the 3d ticket is not evaluable with two days of data, and at the last hour's pace the budget is gone in about 1d 16h. Exit code 1. ## Rules - State the SLO, window, data range and any missing intervals with every result. - Do not mix good-event definitions in one SLI; compute separate SLOs for availability and latency. - An SLO is a decision tool, not a blame tool: describe impact on users, not on people. - Do not invent traffic numbers; if counts are missing, ask for them or say which result cannot be computed. FILE:references/slo-math.md # SLO Math ## Definitions - **SLI** (service level indicator) = good events / total events, as a percentage. - **SLO** (objective) = target SLI over a window, e.g. 99.9% of requests succeed over a rolling 30 days. - **Error budget** = 1 - SLO = the share of events allowed to fail. 99.9% -> 0.1%. - **Budget in events** = (1 - SLO) x total events in the window. - **Error rate** over a window = bad / total in that window. - **Burn rate** = error rate / (1 - SLO). 1.0 means the budget would be exactly used up at the end of the window. ## Projected consumption with partial data With D seconds of data and W seconds of SLO window: - expected requests in window = (requests in data / D) x W - allowed bad = (1 - SLO) x expected requests - consumed = bad in data / allowed bad - time to exhaustion at a recent rate = (allowed bad - bad so far) / (bad per second in that recent window) ## Allowed full downtime | SLO | per 30 days | per 28 days | per week | per day | |---|---|---|---|---| | 99% | 7h 12m | 6h 43m 12s | 1h 40m 48s | 14m 24s | | 99.5% | 3h 36m | 3h 21m 36s | 50m 24s | 7m 12s | | 99.9% | 43m 12s | 40m 19s | 10m 5s | 1m 26s | | 99.95% | 21m 36s | 20m 10s | 5m 2s | 43s | | 99.99% | 4m 19s | 4m 2s | 1m 0s | 9s | Request-based SLOs do not care about clock time directly: 10 minutes of 50% errors costs the same as 5 minutes of full downtime at equal traffic, and an outage at 3 a.m. costs less budget than one at peak. ## Worked example SLO 99.9%, 30d window, 1,000,000 requests per day. - Budget: 0.001 x 30,000,000 = 30,000 failed requests. - A 2% error rate for one hour at 41,667 req/h burns 833 failures = 2.8% of the budget, burn rate 20. - At burn rate 20 the whole budget lasts 30d / 20 = 36 hours. ## Pitfalls - Counting retries as separate good events hides user-facing failures. - Very low traffic (night, new region) makes error rates noisy; use a minimum request count or a longer short window. - Synthetic probes measure the probe, not users; label them separately. - Changing the SLO mid-window: recompute the whole window with the new target and say so. FILE:references/burn-rate-alerting.md # Burn-Rate Alerting ## Default policy (multiwindow, multi-burn-rate) | Severity | Budget share | Long window | Short window | Burn threshold (30d) | Burn threshold (28d) | |---|---|---|---|---|---| | page | 2% | 1h | 5m | 14.4 | 13.44 | | page | 5% | 6h | 30m | 6.0 | 5.6 | | ticket | 10% | 1d | 2h | 3.0 | 2.8 | | ticket | 10% | 3d | 6h | 1.0 | 0.93 | Threshold = budget share x SLO window / long window. Example: 0.02 x 720h / 1h = 14.4. ## Why two windows - The **long window** proves the problem is significant (enough budget spent). - The **short window** (about 1/12 of the long one) proves it is still happening, so the alert resets within minutes after recovery instead of staying red for an hour. - Fire only when both exceed the threshold. ## Example alert rule (Prometheus style) ``` ( sum(rate(http_requests_errors_total[1h])) / sum(rate(http_requests_total[1h])) > (14.4 * 0.001) and sum(rate(http_requests_errors_total[5m])) / sum(rate(http_requests_total[5m])) > (14.4 * 0.001) ) ``` ## Tuning - Low-traffic services: require a minimum number of requests in the short window, or page on 6h only. - Too many pages: check whether the SLO is stricter than users need before raising thresholds. - Missed incidents: slow burns below 1.0 never alert by design; review the budget weekly. - Data step coarser than the short window (e.g. 15-minute buckets): the short window becomes one bucket and recovery detection is slower. ## Budget policy ideas - Over 50% consumed: review risky changes, prefer canaries. - Over 75%: release freeze for non-fixes, reliability work first. - Exhausted: postmortem required; freeze until the rolling window recovers. FILE:templates/slo-status-report.md # SLO Status - <service> - <period or incident> **SLI:** <what counts as good> **SLO:** <target>% over rolling <28d/30d> **Data:** <start> to <end> UTC, step <interval>, <n> missing intervals **Calculator:** `slo_budget.py --slo <target> --window <window>` (exit <code>) ## Budget | Metric | Value | |---|---| | SLI in period | | | Budget consumed | | | Budget remaining | | | Allowed full downtime per window | | ## Burn rates | 5m | 30m | 1h | 2h | 6h | 1d | 3d | |---|---|---|---|---|---|---| | | | | | | | | ## Alerts | Policy | Status | Long / short burn | |---|---|---| | page 1h/5m | | | | page 6h/30m | | | | ticket 1d/2h | | | | ticket 3d/6h | | | ## What happened <worst interval, user impact, cause if known> ## Decision - [ ] Page / incident open - [ ] Release policy: <normal / caution / freeze> because <remaining budget> - [ ] SLO or alert tuning: <change and reason> ## Summary for stakeholders > <service> met <SLI>% against a <target>% target. <x>% of this window's error budget is used; at the current pace it lasts <time>. Next step: <decision>. FILE:examples/checkout-api-requests.csv timestamp,total,good 2026-10-18T00:00:00Z,4757,4755 2026-10-18T00:15:00Z,4525,4523 2026-10-18T00:30:00Z,4313,4311 2026-10-18T00:45:00Z,4122,4120 2026-10-18T01:00:00Z,3951,3949 2026-10-18T01:15:00Z,3803,3801 2026-10-18T01:30:00Z,3678,3676 2026-10-18T01:45:00Z,3577,3576 2026-10-18T02:00:00Z,3500,3498 2026-10-18T02:15:00Z,3448,3446 2026-10-18T02:30:00Z,3421,3419 2026-10-18T02:45:00Z,3019,3018 2026-10-18T03:00:00Z,3044,3043 2026-10-18T03:15:00Z,3093,3092 2026-10-18T03:30:00Z,3169,3168 2026-10-18T03:45:00Z,3270,3268 2026-10-18T04:00:00Z,3396,3394 2026-10-18T04:15:00Z,3547,3545 2026-10-18T04:30:00Z,3722,3720 2026-10-18T04:45:00Z,3921,3919 2026-10-18T05:00:00Z,4143,4141 2026-10-18T05:15:00Z,4388,4386 2026-10-18T05:30:00Z,4253,4251 2026-10-18T05:45:00Z,4539,4537 2026-10-18T06:00:00Z,4845,4843 2026-10-18T06:15:00Z,5168,5166 2026-10-18T06:30:00Z,5509,5507 2026-10-18T06:45:00Z,5865,5863 2026-10-18T07:00:00Z,6236,6234 2026-10-18T07:15:00Z,6619,6616 2026-10-18T07:30:00Z,7013,7009 2026-10-18T07:45:00Z,7418,7414 2026-10-18T08:00:00Z,7831,7827 2026-10-18T08:15:00Z,7850,7847 2026-10-18T08:30:00Z,8274,8271 2026-10-18T08:45:00Z,8702,8699 2026-10-18T09:00:00Z,9132,9127 2026-10-18T09:15:00Z,9561,9556 2026-10-18T09:30:00Z,9989,9984 2026-10-18T09:45:00Z,10413,10408 2026-10-18T10:00:00Z,10832,10827 2026-10-18T10:15:00Z,11245,11240 2026-10-18T10:30:00Z,11650,11645 2026-10-18T10:45:00Z,12044,12038 2026-10-18T11:00:00Z,12028,12022 2026-10-18T11:15:00Z,12398,12392 2026-10-18T11:30:00Z,12754,12748 2026-10-18T11:45:00Z,13095,13089 2026-10-18T12:00:00Z,13418,13412 2026-10-18T12:15:00Z,13724,13719 2026-10-18T12:30:00Z,14010,14003 2026-10-18T12:45:00Z,14275,14268 2026-10-18T13:00:00Z,14520,14513 2026-10-18T13:15:00Z,14742,14735 2026-10-18T13:30:00Z,14941,14934 2026-10-18T13:45:00Z,14716,14710 2026-10-18T14:00:00Z,14867,14861 2026-10-18T14:15:00Z,14993,14985 2026-10-18T14:30:00Z,15094,15086 2026-10-18T14:45:00Z,15170,15163 2026-10-18T15:00:00Z,15220,15213 2026-10-18T15:15:00Z,15244,15237 2026-10-18T15:30:00Z,15242,15236 2026-10-18T15:45:00Z,15215,15209 2026-10-18T16:00:00Z,15163,15155 2026-10-18T16:15:00Z,14686,14679 2026-10-18T16:30:00Z,14585,14578 2026-10-18T16:45:00Z,14460,14453 2026-10-18T17:00:00Z,14312,14306 2026-10-18T17:15:00Z,14141,14135 2026-10-18T17:30:00Z,13950,13866 2026-10-18T17:45:00Z,13738,13656 2026-10-18T18:00:00Z,13506,13499 2026-10-18T18:15:00Z,13257,13251 2026-10-18T18:30:00Z,12990,12984 2026-10-18T18:45:00Z,12708,12702 2026-10-18T19:00:00Z,12012,12007 2026-10-18T19:15:00Z,11702,11697 2026-10-18T19:30:00Z,11382,11376 2026-10-18T19:45:00Z,11051,11045 2026-10-18T20:00:00Z,10712,10707 2026-10-18T20:15:00Z,10367,10362 2026-10-18T20:30: