# Status API reference

GET /v1/status: हर AfterPack service की मौजूदा स्थिति और पिछले 90 दिनों के दैनिक uptime का सार्वजनिक सारांश, वही data जो status.afterpack.dev दिखाता है।

Source: https://www.afterpack.dev/hi/docs/status-api

[status.afterpack.dev](https://status.afterpack.dev) दिखाता है कि हर public AfterPack service चालू है या नहीं, और पिछले 90 दिनों में हर दिन वह कितने समय चालू रहा। यह page एक ही endpoint पढ़ता है, और आप भी उसे पढ़ सकते हैं: किसी monitoring script, dashboard, या ऐसे CI step से जिसे [Pro build](https://www.afterpack.dev/hi/docs/builds) से पहले outage खत्म होने का इंतज़ार करना हो।

## Endpoint

**`GET https://api.afterpack.dev/v1/status`**

न key, न session, न request body। कोई भी origin इसे browser से call कर सकता है। Response 60 सेकंड तक cache हो सकता है (`Cache-Control: public, max-age=60`), इसलिए इसे एक मिनट में एक बार से ज़्यादा poll करने पर कुछ नया नहीं मिलता।

```bash
curl https://api.afterpack.dev/v1/status
```

## Services की जाँच कैसे होती है

एक monitor हर 5 मिनट में Cloudflare के network से हर service की जाँच करता है:

| Service | Host | चालू माना जाता है जब |
|---|---|---|
| API | `api.afterpack.dev` | Health check `"status":"ok"` के साथ `200` लौटाता है। |
| Website | `www.afterpack.dev` | Home page `200` लौटाता है। |

लगातार 2 जाँच विफल होने पर service `down` हो जाती है, और पहली सफल जाँच पर फिर `up` हो जाती है। हर जाँच उस दिन के uptime में गिनी जाती है, वह अकेली विफलता भी जिसने service को `down` नहीं किया।

## Response

```jsonc
{
  "status": "operational",              // overall, see below
  "checkedAt": "2026-10-20T09:15:02Z",  // latest check of any service
  "intervalSeconds": 300,               // time between two checks of a service
  "services": [
    {
      "id": "api",
      "name": "API",
      "host": "api.afterpack.dev",
      "status": "up",                   // up | down | unknown
      "since": "2026-10-18T22:40:01Z",  // when status last changed
      "uptime": 99.982,                 // percent over the 90 days
      "days": [
        { "date": "2026-07-23", "checks": 288, "uptime": 100 },
        // ... one entry per UTC day, oldest first, today last
        { "date": "2026-10-20", "checks": 112, "uptime": 99.107 }
      ]
    }
  ]
}
```

| Field | अर्थ |
|---|---|
| `status` | सभी services चालू हों तो `operational`, कुछ down हों तो `partial_outage`, सभी down हों तो `major_outage`, पहली जाँच से पहले `unknown`। |
| `checkedAt` | सबसे हाल की जाँच कब हुई, या पहली जाँच से पहले `null`। `intervalSeconds` से बहुत पुराना मान बताता है कि monitor खुद रुक गया है। |
| `services[].id` | Service की स्थिर key। |
| `services[].status` | `up`, `down`, या उस service के लिए `unknown` जिसकी अभी जाँच नहीं हुई। |
| `services[].since` | Service आखिरी बार कब up या down हुई, या उसकी पहली जाँच से पहले `null`। |
| `services[].uptime` | 90 दिनों में सफल जाँचों का हिस्सा, प्रतिशत में, या जाँच न होने पर `null`। |
| `services[].days` | ठीक 90 entries, हर UTC दिन की एक। बिना जाँच वाले दिन `uptime` `null` होता है। |

Uptime के आँकड़े तीन दशमलव तक नीचे की ओर round होते हैं, इसलिए एक विफल जाँच वाला दिन `99.652` दिखाता है और कभी `100` नहीं। इस response में fields जोड़े जा सकते हैं; मौजूदा fields का अर्थ वही रहता है, जैसा पूरे [Cloud API](https://www.afterpack.dev/hi/docs/cloud-api) में है।

## जब API तक नहीं पहुँचा जा सके

यह endpoint खुद API देता है, इसलिए जब `api.afterpack.dev` जवाब नहीं दे पाता, तब `/v1/status` भी नहीं। तब status page [Cloudflare का status](https://www.cloudflarestatus.com) पढ़ता है और बताता है कि Cloudflare अपनी कोई समस्या report कर रहा है या नहीं। Script में भी `/v1/status` के विफल request को इसी तरह लें: API के down होने के रूप में।

## आगे

- [SLA, SLO और सपोर्ट](https://www.afterpack.dev/hi/docs/sla): वह availability target जिसे ये जाँचें मापती हैं।
- [Cloud API reference](https://www.afterpack.dev/hi/docs/cloud-api): बाकी API, और उसका versioning।
- [Builds और CI](https://www.afterpack.dev/hi/docs/builds): API down होने पर Pro build क्या करता है।