| 1 | --- |
| 2 | title: Status and incidents |
| 3 | description: Where to see whether g1t is working, what each check measures, how incidents and maintenance are posted, how to subscribe, and the JSON and feeds behind the page. |
| 4 | --- |
| 5 | |
| 6 | [status.g1t.sh](https://status.g1t.sh/) says whether each part of g1t is |
| 7 | working now, how each has done over the last 90 days, what g1t staff have |
| 8 | said about anything that went wrong, and what planned maintenance is |
| 9 | coming. It runs as a service of its own, apart from the site, so it stays |
| 10 | up when g1t.sh does not. |
| 11 | |
| 12 | The account menu at the bottom of the sidebar shows the same state as a |
| 13 | dot beside **Status**, and so does the footer of g1t.sh's public pages. |
| 14 | |
| 15 | ## What is checked |
| 16 | |
| 17 | Every minute, each part gets one quick request, the same one a visitor |
| 18 | would make, over the public internet: |
| 19 | |
| 20 | | Part | What the check does | |
| 21 | | --- | --- | |
| 22 | | Website and sign-in | Loads `g1t.sh/login`, and asks the API about an access token no one holds, which the account service must refuse with `401` | |
| 23 | | API | Loads `api.g1t.sh/` | |
| 24 | | Git and repositories | Lists the branches of a public repository over HTTPS (`info/refs`), the first step of every clone | |
| 25 | | Git storage | How the store that keeps every repository (Cloudflare Artifacts) answered g1t over the last five minutes. Down when a quarter or more of its calls failed, or g1t stopped asking after repeated failures; degraded when it rate limited g1t, its calls took over 1.5 seconds on average, or g1t is serving repositories from its backup store (reads work, pushes and merges wait) | |
| 26 | | Page speed | Loads a public project page (`g1t.sh/flagon-io/g1t`) and `g1t.sh/explore`, timed to the first byte of each answer | |
| 27 | | MCP server | Loads `mcp.g1t.sh/` | |
| 28 | | Documentation | Loads `docs.g1t.sh/` | |
| 29 | | Deployments | Loads `g1t.page/`. Each deployed app is not checked one by one. | |
| 30 | | Agents' model proxy | Loads `models.g1t.sh/`. The model providers behind it are not checked. | |
| 31 | | Sandboxes | Not checked yet: starting a sandbox costs money and takes seconds. The page says so rather than showing green. | |
| 32 | | Billing | Reads billing's price book. Stripe itself is not checked. | |
| 33 | |
| 34 | A part that answers in over 1.5 seconds counts as slow, and one that |
| 35 | fails or takes over 5 seconds counts as down. **Page speed** is held to |
| 36 | a tighter budget: slower than 800 ms on either page counts as slow. |
| 37 | |
| 38 | ## What each part shows |
| 39 | |
| 40 | A part shows the worse of its last check and what an open incident says |
| 41 | about it. During planned maintenance it shows **Under maintenance** |
| 42 | instead, unless an incident says something worse. |
| 43 | |
| 44 | | State | Meaning | |
| 45 | | --- | --- | |
| 46 | | Operational | Its check answered quickly, and no incident says otherwise | |
| 47 | | Degraded | Slow to answer, or an incident reports degraded performance | |
| 48 | | Partial outage | An incident reports that it is partly down | |
| 49 | | Outage | Its check failed, or an incident reports a major outage | |
| 50 | | Under maintenance | Planned work on it is under way | |
| 51 | | Not monitored | It has no check, and no incident is open on it | |
| 52 | |
| 53 | The banner at the top sums them up: |
| 54 | |
| 55 | | Banner | When | |
| 56 | | --- | --- | |
| 57 | | All systems normal | Every checked part answered quickly, and no incident is open | |
| 58 | | Under maintenance | Planned work is under way, and nothing else is wrong | |
| 59 | | Degraded performance | Some parts are slow, and none is down | |
| 60 | | Partial outage | A part other than the website, API or git is down, a part is partly down, or an incident is open | |
| 61 | | Major outage | The website, the API or git is down, or an open incident reports a major outage | |
| 62 | |
| 63 | ## Uptime bars |
| 64 | |
| 65 | Each part has a bar of 90 days, one square per day in UTC, newest on the |
| 66 | right. Hover over a square, tap it, or focus the bar and use the arrow |
| 67 | keys to see that day's share of answered checks, failed and slow checks, |
| 68 | the average response time, and any incident. On a phone the bar shows |
| 69 | the last 30 days. |
| 70 | |
| 71 | | Square | The day | |
| 72 | | --- | --- | |
| 73 | | Green | At least 99.9% of checks answered, so one failed check in a day stays green | |
| 74 | | Peach | At least 95% answered, over a quarter of answers were slow, or an incident with degraded performance or a partial outage on the part was open | |
| 75 | | Red | Less than 95% answered, or an incident with a major outage on the part was open | |
| 76 | | Gray | No checks yet | |
| 77 | |
| 78 | The percentage under each bar is the share of checks that answered over |
| 79 | 90 days, rounded down, so a single failure never shows as 100%. Checks |
| 80 | made while a part is under planned maintenance are not counted. |
| 81 | |
| 82 | ## Incidents |
| 83 | |
| 84 | When something goes wrong, g1t staff post an incident: a title, the |
| 85 | parts it affects and how badly, and updates as it moves from |
| 86 | **Investigating** to **Identified**, **Monitoring** and **Resolved**. |
| 87 | |
| 88 | - Open incidents are shown at the top under **Happening now**, with every |
| 89 | update, newest first. |
| 90 | - Each incident has a page of its own at |
| 91 | `https://status.g1t.sh/incidents/<id>`, with its full history. Links in |
| 92 | emails and feeds go there. |
| 93 | - Incidents resolved in the last 14 days are listed under **Past |
| 94 | incidents**; [History](https://status.g1t.sh/history) lists every |
| 95 | incident and maintenance of the last 12 months, by month. |
| 96 | - After a significant incident, g1t publishes a **postmortem** on the |
| 97 | incident's page: a summary, the impact, a timeline, the root cause, what |
| 98 | went well and badly, and what will change. Incidents with one are marked |
| 99 | **Postmortem** in the lists. |
| 100 | - Times are shown in your time zone, with its abbreviation (`PDT`, |
| 101 | `CEST`); hover one to see it in UTC. The JSON, the feeds and email keep |
| 102 | UTC. |
| 103 | |
| 104 | ### Severity |
| 105 | |
| 106 | Staff give every incident a severity. It decides how fast the team |
| 107 | responds and how often it posts updates; it is not shown on the status |
| 108 | page, which shows each part's impact instead. |
| 109 | |
| 110 | | Severity | Meaning | Public updates | |
| 111 | | --- | --- | --- | |
| 112 | | SEV1 | Critical: g1t is down or unusable for most people, or data is at risk | At least every 30 minutes; subscribers are emailed | |
| 113 | | SEV2 | Major: a core part (sign-in, git, the API, agents) is broken or badly degraded for many people | At least hourly; subscribers are emailed | |
| 114 | | SEV3 | Minor: one part is degraded or broken for some people, and there is a way around it | As things change | |
| 115 | | SEV4 | Low: little or no customer impact | As things change | |
| 116 | |
| 117 | ### Noticed before anyone reports it |
| 118 | |
| 119 | When a part fails, or is slow, on four of five checks in a row, g1t |
| 120 | staff are alerted and an incident is drafted for them. It appears on the |
| 121 | status page once someone confirms it, usually within minutes. The part's |
| 122 | own state on the page changes at once either way, because it comes from |
| 123 | the checks. |
| 124 | |
| 125 | A brief blip does not become an incident. A slow answer is checked again |
| 126 | straight away, and counts as slow only if the second answer is slow too. |
| 127 | If the part recovers and stays healthy for 10 minutes before anyone |
| 128 | confirms the draft, the draft is dismissed and never appears on the page. |
| 129 | While g1t is deploying, and for 3 minutes after, a slow restart is not |
| 130 | drafted unless it outlasts the deploy. |
| 131 | |
| 132 | **Page speed** is timed to the first byte of each page, loaded as a |
| 133 | browser loads it. The checks identify themselves as `g1t-status/1.0` at |
| 134 | the end of a browser's user agent. |
| 135 | |
| 136 | If something is broken and the page does not show it, write to |
| 137 | [hey@flagon.io](mailto:hey@flagon.io) or see |
| 138 | [support](https://g1t.sh/support). |
| 139 | |
| 140 | ## Planned maintenance |
| 141 | |
| 142 | Work that may interrupt a part is announced ahead of time: |
| 143 | |
| 144 | 1. It is listed under **Upcoming maintenance** with its window (start and |
| 145 | end, shown in your time zone), the parts it affects, and what you may |
| 146 | notice. |
| 147 | 2. When the window opens, it moves to **Maintenance in progress**, and its |
| 148 | parts show **Under maintenance**. |
| 149 | 3. When the window ends, it is marked complete on its own, with an update |
| 150 | saying so. Staff can also start it early, finish it early, or cancel it. |
| 151 | |
| 152 | Each maintenance window has a page at |
| 153 | `https://status.g1t.sh/maintenance/<id>`. |
| 154 | |
| 155 | ## Subscribe to updates |
| 156 | |
| 157 | Get an email when an incident or maintenance is posted or updated: |
| 158 | |
| 159 | 1. Enter your address under **Subscribe to updates** on |
| 160 | [status.g1t.sh](https://status.g1t.sh/), or on |
| 161 | [status.g1t.sh/subscribe](https://status.g1t.sh/subscribe) to choose |
| 162 | which parts you hear about. Leave every part clear to hear about all of |
| 163 | them. |
| 164 | 2. Open the email from `noreply@g1t.sh` and follow **Confirm |
| 165 | subscription**, then press the button on the page. The link works once, |
| 166 | for 24 hours. Nothing is sent until you confirm. |
| 167 | 3. To change which parts you hear about, subscribe again with the same |
| 168 | address and confirm again. |
| 169 | |
| 170 | Every email has an **Unsubscribe** link at the bottom, and mail apps that |
| 171 | support one-click unsubscribing show it too. Staff choose per update |
| 172 | whether to email: SEV1 and SEV2 updates are emailed, smaller ones may |
| 173 | not be. The feeds carry every update. |
| 174 | |
| 175 | ## Feeds |
| 176 | |
| 177 | Every public incident update and maintenance notice, newest first, the |
| 178 | last 50: |
| 179 | |
| 180 | | Feed | Address | |
| 181 | | --- | --- | |
| 182 | | Atom (feed readers, Slack's RSS app, and most chat tools) | `https://status.g1t.sh/feed.xml` | |
| 183 | | JSON Feed 1.1 | `https://status.g1t.sh/feed.json` | |
| 184 | |
| 185 | Each item links to the update on its incident's or maintenance's page. |
| 186 | |
| 187 | ## The status as JSON |
| 188 | |
| 189 | `GET https://status.g1t.sh/status.json` returns the same report, readable |
| 190 | from any origin and cached for 30 seconds: |
| 191 | |
| 192 | ```sh |
| 193 | curl -s https://status.g1t.sh/status.json |
| 194 | ``` |
| 195 | |
| 196 | ```json |
| 197 | { |
| 198 | "checked_at": "2026-10-05T14:03:00.000Z", |
| 199 | "overall": { |
| 200 | "state": "up", |
| 201 | "title": "All systems normal", |
| 202 | "line": "Every part of g1t answered its last check." |
| 203 | }, |
| 204 | "components": [ |
| 205 | { |
| 206 | "key": "api", |
| 207 | "name": "API", |
| 208 | "address": "api.g1t.sh", |
| 209 | "checks": "The API's front page.", |
| 210 | "state": "up", |
| 211 | "check_state": "up", |
| 212 | "detail": "Answered in 84 ms", |
| 213 | "latency_ms": 84, |
| 214 | "uptime_90d": 99.98 |
| 215 | } |
| 216 | ], |
| 217 | "incidents": [], |
| 218 | "maintenance": [] |
| 219 | } |
| 220 | ``` |
| 221 | |
| 222 | | Field | What it is | |
| 223 | | --- | --- | |
| 224 | | `overall.state` | `up`, `degraded`, `down`, `maintenance`, or `unknown` before the first check | |
| 225 | | `components[].state` | What the page shows: `up`, `degraded`, `partial`, `down`, `maintenance`, or `unmonitored` | |
| 226 | | `components[].check_state` | What the last check alone said: `up`, `degraded`, `down` or `unmonitored` | |
| 227 | | `components[].uptime_90d` | Share of checks answered over 90 days, 0 to 100, or `null` | |
| 228 | | `incidents[]` | Open incidents, and those resolved in the last 90 days, newest first | |
| 229 | | `incidents[].status` | `investigating`, `identified`, `monitoring` or `resolved` | |
| 230 | | `incidents[].impact` | `down` when any part has a major outage, otherwise `degraded` | |
| 231 | | `incidents[].component_impacts` | Each affected part's `key` and `impact`: `degraded`, `partial_outage` or `major_outage` | |
| 232 | | `incidents[].url` | The incident's page | |
| 233 | | `incidents[].postmortem_published_at` | When its postmortem was published, or `null` | |
| 234 | | `incidents[].updates` | Newest first, each with `id`, `at`, `status` and `text` | |
| 235 | | `maintenance[]` | Maintenance scheduled or under way, soonest first, each with `title`, `message`, `components`, `starts_at`, `ends_at`, `state` (`scheduled` or `in_progress`), `url` and `updates` | |
| 236 | |
| 237 | `https://status.g1t.sh/badge.svg` is a small badge with the banner's |
| 238 | words, for a README or a dashboard. |
| 239 | |
| 240 | The old addresses, `g1t.sh/status` and `g1t.sh/status.json`, redirect |
| 241 | here. |