Fly.io की समस्या का समाधान पूरा

 (status.flyio.net)
1 पॉइंट द्वारा GN⁺ 2024-11-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Fly.io status page पर फिलहाल All Systems Operational है, और app execution, dashboard, Machines API, regional availability जैसे प्रमुख components operational हैं
  • Jul 1, 2026 की Elevated API Errors समस्या GraphQL API errors और background job processing की समस्या ठीक करने के बाद 07:50 UTC पर resolve हुई
  • Jun 30 की Delayed Metrics समस्या ने कुछ ग्राहकों के fly-metrics.net dashboard में delayed/missing metrics पैदा किए, और backlog processing व capacity बढ़ाने के बाद स्थिति सामान्य हुई
  • यह status page global incidents updates के लिए है, इसलिए सीमित असर वाले hardware failures या isolated infrastructure events इसमें शामिल नहीं हैं
  • app-specific impact Fly Organization dashboard के personalized status page पर देखना चाहिए, और internal incidents व activity के लिए Infra Log देखने को कहा गया है

मौजूदा service status

  • Fly.io status page फिलहाल All Systems Operational स्थिति में है
  • operational के रूप में दिखाए गए प्रमुख items हैं: Customer Applications, Dashboard, Machines API, Regional Availability, Persistent Storage (Volumes), Deployments, Remote Builds, Logs, Metrics, SSL/TLS Certificate Provisioning, UDP Anycast, Fly Machine Image Registry 1·2, Extensions, Upstash for Redis, DNS, Billing, Managed Postgres
  • regional status भी operational दिख रहा है, और target regions हैं AMS, ARN, BOM, CDG, DFW, EWR, FRA, GRU, IAD, JNB, LAX, LHR, NRT, ORD, SIN, SJC, SYD, YYZ

status page का scope

  • यह page global incidents updates के लिए है
  • सीमित असर वाले routine hardware failures या isolated infrastructure events के updates इसमें शामिल नहीं हैं
  • आपके app को प्रभावित कर सकने वाली सभी events का personalized view Fly Organization dashboard के personalized status page पर देखना चाहिए
  • internal incidents और अन्य activity Infra Log में देखने के लिए कहा गया है

Jul 1, 2026: Elevated API Errors

  • Elevated API Errors को Jul 1, 07:50 UTC पर Resolved किया गया
  • 06:14 UTC पर GraphQL API और background job processing में elevated errors की investigation शुरू हुई
  • 06:27 UTC पर cause identify हुआ और fix पर काम शुरू हुआ
  • 07:05 UTC पर fix apply हुआ और elevated API errors अब दिखाई नहीं दे रहे थे
    • कुछ dashboard operations में background processing के catch up करने तक delay हो सकता था
  • 07:26 UTC पर background jobs catch up कर चुके थे, और API पूरी तरह operational स्थिति में monitor होती रही

Jun 30, 2026: Delayed Metrics और SIN/NRT egress IP

  • Delayed Metrics Jun 30, 22:19 UTC पर resolve हुई
  • fly-metrics.net dashboard के customer metrics में समस्या आई, जिससे users delayed या missing metrics देख सकते थे
  • कई hosts की problems के कारण metrics collection delay हुआ, और कुछ metrics ingestion hosts में resource contention को cause के तौर पर handle किया गया
  • backlog process करने के लिए metrics cluster throughput बढ़ाया गया, और ingestion traffic rebalancing व additional processing capacity लगाई गई
  • Jun 30, 19:58 UTC पर लगभग सभी metrics catch up कर चुके थे, लेकिन sin और syd के कुछ metrics बाकी थे
  • Egress IP issues in SIN and NRT Jun 30, 14:03 UTC पर resolve हुई
    • SIN और NRT में egress IP इस्तेमाल करने वाली कुछ Machines अस्थायी रूप से connectivity खो सकती थीं या performance degradation झेल सकती थीं

Jun 26~25, 2026: network, deployment और control plane incidents

  • IPv6 Connectivity Issues in EWR Jun 26, 23:48 UTC पर resolve हुई
    • upstream provider की IPv6 network connectivity problem EWR में हुई
    • affected hosts पर Machines वाले apps specific IPv6 destinations से connectivity में impact देख सकते थे
  • Network maintenance in YYZ Jun 26, 08:00~09:00 UTC के बीच scheduled maintenance था और पूरा हुआ
    • maintenance window के दौरान अधिकतम 15 मिनट connectivity loss expected था
  • Deploys defaulting to Fly-hosted Builders Jun 25, 15:38 UTC पर resolve हुई
    • Depot backed builders provisioning delay की investigation के दौरान default fly deploy strategy Fly-hosted builders पर switch की गई
    • users fly deploy --depot=true से Depot-based deployment force कर सकते थे, और बाद में fly deploy --depot=false से Fly builder-based deployment भी संभव था
  • Elevated control plane latency Jun 25, 15:18 UTC पर resolve हुई
    • BOM और NRT regions को प्रभावित करने वाली control plane latency और saturation हुई
    • इन regions में Machines वाले apps को longer response times और possible 502 errors का सामना करना पड़ सकता था

Jun 24~17, 2026: North America, SIN/NRT network और log search

  • Degraded networking in North America Jun 24, 06:57 UTC पर resolve हुई
    • North America sites के बीच network performance degradation को upstream incident के कारण investigate किया गया
    • कुछ Machines specific routes पर packet loss और higher latency देख सकती थीं
    • LAX region से/तक जाने वाले कुछ 6PN Private Networking traffic पर असर बाकी था
  • Network issues in SIN, NRT Jun 22, 21:56 UTC पर resolve हुई
    • upstream provider को SIN और NRT regions में network problems हुईं, और उन regions के apps unreachable या high packet loss का सामना कर सकते थे
  • SIN, NRT network issues Jun 22, 19:48 UTC पर resolve हुई
    • शुरुआत में इसे SIN region upstream network issue के रूप में investigate किया गया, और बाद में NRT region के apps भी specific destinations तक पहुंचने में problem झेल सकते थे
  • Log search unavailable Jun 19, 21:53 UTC पर resolve हुई
    • इसने Fly Metrics log search panels और fly logs command में पहले return होने वाले historical application logs को प्रभावित किया
    • fly logs streaming, dashboard का Live Logs page, और Fly Log Shipper services सामान्य रूप से काम करते रहे
    • fix के बाद historical logs backfill किए गए, और अधिकांश queued historical logs searchable हो गए
  • Network Issues in SIN Jun 17, 04:55 UTC पर resolve हुई
    • SIN region में network connectivity problem थी और hosted apps unavailable हो सकते थे
    • कुछ Machines unreachable थीं, और कुछ Managed Postgres clusters fail-over या update में fail हो सकते थे

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-11-27
Hacker News की रायें

  • fly.io पर होस्ट की गई मेरी वेबसाइट करीब 6 घंटे पहले 5 मिनट के लिए डाउन हुई थी और तुरंत रिकवर हो गई; उसके बाद से लगातार ठीक चल रही है
    एक free monitoring service हर 5 मिनट में चेक करती है, इसलिए हो सकता है कि उससे छोटा downtime छूट गया हो, लेकिन कुल मिलाकर यह काफी stable रही

    • कुछ महीनों का डेटा देखना दिलचस्प होगा
      application uptime भी अस्थिर है, लेकिन उससे भी खराब बात यह थी कि fly deploy failures बिना किसी वजह के हो जाते थे। कभी-कभी layer बस अटक जाती थी और आखिर में fail हो जाती थी, और 1–2 घंटे बाद बिना कोई बदलाव किए वही command फिर चलाने पर ठीक काम करती थी
      मैं ऐसी monitoring service देखना चाहूंगा जो हर 5 मिनट में एक basic app deploy करके, यानी fly deploy command को नियमित रूप से चलाकर, यह बताए कि deployment कितनी बार fail होता है या अटकता है। लगता है करीब 5% बार बिना explanation के fail होगा, और अगर आपके पास समय कम हो तो यह काफी परेशान करने वाला स्तर है
    • fly.io और उसके docs को बाहर से monitor कर रहा हूं: https://flyio.onlineornot.com/
      इस हिसाब से यह 16 मिनट तक जारी रहा लगता है
    • हमारे यहां भी लगभग 5 मिनट के लिए down हुआ, फिर recover हो गया और उसके बाद ठीक रहा; error 501 था

  • fly.io ने postmortem यहां public किया है: https://fly.io/infra-log/
    हाल का postmortem काफी दिलचस्प और detail-heavy है। 2016 में fly.io के operations infrastructure का core component consul नाम का एक high-security TLS server था, जिसे shared state track करते हुए server certificates और client certificates दोनों authenticate करने पड़ते थे
    centralized structure होने से scalability issues आए, और fly.io ने 2020 में इसे replace करने के लिए corrosion बनाया और consul को जल्दी ही भूल गया, लेकिन उसे पूरी तरह हटाया नहीं जा सका
    फिर अक्टूबर 2024 में consul की root key signing key expire हो गई, जिससे सभी connections down हो गए। क्योंकि यह mutual authentication इस्तेमाल करता है, इसलिए पूरे fleet में नए SSL certificates deploy करने से पहले recovery संभव नहीं थी। किसी तरह उन्होंने 30 मिनट में यह कर लिया, लेकिन तब तक domino effect शुरू हो चुका था और infrastructure की दूसरी कमजोरियां भी सामने आ गईं
    एक और internal service की independent TLS key set बहुत पहले expire हो चुकी थी, लेकिन consul key reissue process में restart करने तक यह पता नहीं चला। जब certificates valid थे तब बने TCP connections restart के कारण टूटे, तब यह बात सामने आई। उसी दौरान logging tool network provider पर DDoS जैसा traffic मार रहा था। जब इतनी सारी चीजें एक साथ फट पड़ीं, तब company को बचाने और customers को भी सुरक्षित रखने वाले लोग सच में कमाल के थे

    • उस Consul outage पर Fly Infra ने निष्कर्ष निकाला कि “सीख यह है कि अब कोई आधे-अधूरे उपाय नहीं”
      लेकिन hiring page [1] पर वे कहते हैं, “हम technical debt में ज्यादा विश्वास नहीं करते”
      बाहर से देखने पर यह विरोधाभासों का कोरस जैसा पढ़ता है
      [1] https://fly.io/docs/hiring/working/#we-re-ruthless-about-doi...

  • Fly.io काफी दो पहलुओं वाली सेवा लगती है
    https://news.ycombinator.com/item?id=41917436
    https://news.ycombinator.com/item?id=35044516
    https://news.ycombinator.com/item?id=34742946
    https://news.ycombinator.com/item?id=34229751
    अगर कोई cloud platform reliability ठीक से नहीं दे पाता, तो मेरी नजर में उसकी उतनी value नहीं है। बेहतर हो सकता है कि बस virtual server किराए पर लेकर cloud tax बचा लिया जाए

    • प्रयोगों या hobby projects के लिए इसका value proposition शानदार है। महीने के $1.94 में independent instance चलाने की सुविधा और कहां मिलती है
      हालांकि यह कीमत 256MB RAM वाले instance के लिए है (https://fly.io/docs/about/pricing/)। फिर भी उस पर meaningful projects चलाना बिल्कुल संभव है। Rocket जैसे Rust-based web server को करीब 10MB RAM ही चाहिए, और जितना मैंने देखा है, basic PHP server भी उसमें फिट हो सकता है
    • Reliability वाकई बहुत खराब है। पिछले कुछ महीनों में मेरे demo के दौरान main dashboard दो बार down हो गया, यह समझ से बाहर था
      deployment outages तो थे ही, लगभग हर दिन कुछ न कुछ randomly काम नहीं करता था या delay होता था
      price increase और मेरे boss ने Fly पर डाले गए मेरे project में कई बार problems देखीं, इस वजह से मुझे कुछ महीने पहले छोड़ना पड़ा
      ऊपर से sqlite backup service भी deprecated करके हटा दी गई। अब मैं GCP पर वापस हूं और ढेरों outages की चिंता नहीं करता
    • मुझे fly.io का value proposition ठीक से समझ नहीं आता। outages के बावजूद engineering team impressive है, लेकिन क्या edge computing सच में 99.9% developers को चाहिए?
      कई बड़ी कंपनियों की services एक single AWS region से चलती हैं और दुनिया भर में लाखों लोग उन्हें इस्तेमाल करते हैं। यह कुछ ऐसा लगता है जो default से ही premature optimization को enable करता है
    • यह नजरिया पूरी तरह reasonable है, और मैं इसका विरोध करने की कोशिश नहीं करूंगा। हम बहुत कठिन चीज बना रहे हैं, कंपनी अपेक्षाकृत नई है, और hyperscalers के resources का बहुत छोटा हिस्सा भी हमारे पास नहीं है। AWS, GCP, OCI जब शुरू हुए थे, उनकी तुलना में भी ऐसा ही है
      अगर लक्ष्य reliability को maximize करना है, तो वह भी पूरी तरह reasonable choice है। 2024 में UE1 में हम बेहतर हैं, ऐसा मैं नहीं कहूंगा
      संदर्भ के लिए, कई चीजें गलत हो सकती हैं और सच में होती भी हैं, लेकिन यहां आपको सबसे ज्यादा दिखने वाले outage का प्रकार शायद वह समय होगा जब deployment नहीं हो पाता। यह outage deployment/orchestration outage था। कुछ महीने पहले Rust concurrency landmine की वजह से पूरा request routing outage हुआ था, लेकिन ऐसी घटनाएं बहुत दुर्लभ हैं
      deployment और state update outages भी बड़ी बात हैं, और अगर आप हमारी recommendation के अनुसार अलग-अलग Fly Machines groups में लगातार deploy करते हैं, तो platform की बड़ी capabilities में से एक होने के कारण यह availability को प्रभावित कर सकता है। मैं इसे छोटा करके नहीं बताना चाहता
    • fly.io की reliability के मामले में reputation बहुत खराब है, और Hacker News के बाहर image recovery भी खास नहीं दिखती। यहां तक कि यहां भी consensus कुछ ऐसा लगता है कि “critical workloads fly.io पर मत चलाओ और data redundancy की उम्मीद मत करो”
      असल में अपने bare metal servers पर Firecracker चलाकर, fly.io जो करता है लगभग वही चीज और सस्ते में की जा सकती है
      fly.io को लेकर public perception अब शायद सुधारना मुश्किल हो चुका है। अब तो यह भी गिनना मुश्किल है कि कितनी बार माफी मांगी जा चुकी है

  • लेख के title के उलट Fly.io API अभी भी inaccessible है। इसका मतलब है कि users अभी भी deployments, databases आदि access नहीं कर सकते
    सही update के लिए https://community.fly.io/t/fly-io-site-is-currently-inaccess... देखें

  • Fly.io और Railway.com दोनों इस्तेमाल करने के मेरे personal experience में Railway साफ विजेता है। Railway support भी तुलना में शानदार है
    Fly.io ने support email पर भेजी गई data deletion query का अब तक जवाब नहीं दिया है
    Railway app अब तक बिना बड़े downtime के online रही है। जो लोग अच्छा alternative खोज रहे हैं, उन्हें Railway आजमाने की सलाह दूंगा

    • मैंने Railway control panel कुल मिलाकर शायद 10 बार इस्तेमाल किया है, और उनमें से आधी बार अजीब problems थीं। control panel UI load नहीं हुआ या काम नहीं कर रहा था, tasks fail हुए, deployments randomly fail हुए
      idea अच्छा है, लेकिन असल में इसे serious use के लिए नहीं अपनाना चाहूंगा
    • Fly अपने खुद के hardware पर बना है। क्या Railway भी यही तरीका अपनाता है? अगर नहीं, तो Railway में अपेक्षाकृत कम outages होने की वजह का कुछ हिस्सा इससे समझ आता है। क्योंकि engineer करने के लिए चीजें कम हैं
      मैं समझता हूं कि end users reliability चाहते हैं, और यह भी जानता हूं कि Fly ने पिछले 2 सालों में इसमें काफी investment किया है, फिर भी reputation खराब है। लेकिन ऐसे outages ऐसे नहीं हैं जो एक provider में हों और दूसरे में न हों। cloud infrastructure बनाना किसी के लिए भी आसान नहीं है

  • मैंने खुद देखा है कि Fly.io का major outage शायद यह 5वां या 6वां है। और भी outages रहे होंगे, जिनमें से कुछ शायद मैं देख ही नहीं पाया
    मैंने एक दोस्त को यह service recommend की थी, और दो दिनों के अंदर उसने दो outages झेले
    Fly.io को सच में संभलने की जरूरत है। यह अब तक क्यों नहीं हो पाया, यह रहस्य है। product अच्छा है, लेकिन hosting service के लिए stability सबसे पहली priority होनी चाहिए। बाकी सब secondary है

    • बात समझता हूं, लेकिन अगर लोग GitHub के हर 2 हफ्ते में बड़े पैमाने पर टूटने को माफ कर देते हैं, तो Fly को भी कुछ goodwill दी जा सकती है। मेरा Fly से कोई संबंध नहीं है, लेकिन जब बड़ी कंपनियां भी ठीक से नहीं कर पा रहीं, तो expectations कम करने की जरूरत है
      secret शायद यह है कि ऐसा incumbent बनो जिसका कोई ठीक substitute न हो। तब reliability के मामले में पूरी तरह mess होने पर भी सभी operational failures को हल्के में ले लेते हैं
    • करीब 1 साल पहले reliability issues की वजह से छोड़ दिया था। अब DigitalOcean Apps इस्तेमाल कर रहा हूं और यह बहुत अच्छे से काम करता है। DO पर downtime 0 रहा है
    • अगर traffic scale exponential तरीके से बढ़ रहा हो, तो reliability बनाए रखना मुश्किल होता है
    • free tier से आगे सच में कोई इस्तेमाल करता है क्या? Vercel भी ऐसा ही है

  • अजीब बात यह है कि Turso में भी लगभग उसी समय समस्या शुरू हुई। CEO ने Discord पर पुष्टि की कि यह Fly की outage की वजह से था

    Ok.I caught up with our oncall and This seems related to the Fly.io incident that is reported in our status page. Our login does call things in the Fly.io API
    we are already in touch with Fly and will see if we can speed this up

    • यह पहली बार नहीं है कि Turso, Fly की समस्या के कारण down हुआ हो। Database service बनाकर ऐसी downtime झेलनी पड़े तो वाकई बहुत तकलीफदेह होगा
      लगता है Turso किसी समय AWS tier देने की योजना में है

  • हैरानी की बात नहीं। करीब 1 साल पहले कम कीमतों की वजह से मैंने fly.io को देखा था, और सोच रहा था कि वे खर्च कहाँ घटाकर पैसा कमाते हैं। आखिरकार जवाब तकनीकी docs में मिला: वहाँ साफ लिखा था कि fly instance एक physical server से fixed रहता है और अगर वह server मर जाए तो failover संभव नहीं है। पता नहीं वह हिस्सा अभी भी official docs में है या नहीं
    असल में इसका मतलब है: server down हो जाए तो उस instance का आखिरी snapshot backup से लोड करके नए server पर चढ़ाना, network route update करना, और फिर दुआ करना कि spare capacity से ज्यादा servers न मरें। नहीं तो recovery के लिए data center में rack में कुछ और servers लगाने तक इंतजार करना पड़ेगा
    इसलिए outage reports random जैसी दिखती हैं, यह भी काफी समझ आता है। कुछ apps down हैं, बाकी ठीक हैं; कुछ apps 5 मिनट में लौट आते हैं, बाकी में काफी समय लगता है
    अगर business का budget tight है, तो छोटे civo cluster जैसे दूसरे विकल्प बेहतर लगते हैं

    • Fly.io अब VM और volumes migrate कर सकता है: https://fly.io/docs/reference/machine-migration/ / https://archive.md/rAK0V
      “fly instance एक physical server से fixed रहता है और failover संभव नहीं है” वाली बात में, इसके अलावा होना क्या चाहिए, यह मुझे ठीक से समझ नहीं आता। live migration होती है, यह पता है, लेकिन उस स्थिति में भी VM आखिर किसी न किसी physical server पर तो “fixed” ही रहता है, नहीं?
    • ज्यादातर EC2 instance types में भी बहुत हाल तक live migration नहीं थी। कुछ में शायद अब भी नहीं है। कब और कैसे काम करती है, यह भी साफ-साफ नहीं लिखा होता
      और यह मुफ्त भी नहीं है। उदाहरण के लिए GCP में जब VM migrate होता है, तो महसूस होने वाली थोड़ी देर की performance गिरावट होती है
    • अगर Fly पर high availability चाहिए, तो app को कई regions, यानी कई machines पर deploy करना होगा
      proxy layer fail हो जाए तो पूरा Fly फिर भी down हो सकता है, लेकिन ऐसे मामले बहुत कम आम हैं
    • status page देखकर यह high availability/clustering system failure जैसा लगता है। इस बार मामला ऐसा ज्यादा लगता है जहाँ high availability equipment की complexity ने availability को, साधारण VPS जैसी configuration की तुलना में, उल्टा नुकसान पहुँचाया

  • बार-बार दिखने वाला pattern यह है कि अमेरिका की बड़ी छुट्टियों वाले सप्ताह में outages अक्सर होती हैं
    MS 365/Teams/Exchange में भी सुबह थोड़ी देर समस्या थी, Fly.io पूरी तरह outage में था, और फिर कई sites और services उसके असर से हिल गईं
    आम तौर पर मैं “change freeze” के खिलाफ हूँ, लेकिन बड़ी छुट्टियों के आसपास change freeze समझ में आता है। इससे सभी teams को recharge, break और maintenance का समय मिल सकता है
    बेहतर है कि इत्तफाक से on-call बनी B team पर बहुत ज्यादा दबाव न डाला जाए

    • इस scale की outage में खराब code वजह कम ही होता है। दोषी लगभग हमेशा configuration change होता है
      छुट्टियों के मौसम में ऐसे changes भी घटाने की कोशिश की जा सकती है, लेकिन अगर certificate renew करना पड़े तो? जरूरी security patch लगाना पड़े तो? servers के समूह को फिर से provision करना पड़े तो? hard disk space कम पड़ जाए तो?
      साल के किसी भी समय operational मुश्किलों को केवल planning से टाला नहीं जा सकता
    • यह टाला नहीं जा सकता कि ऐसे holiday weeks सामान्य दिनों से अलग होते हैं। “change freeze” लगाने पर आमतौर पर पूरे system में होने वाले छोटे fixes और performance tuning भी “important नहीं” होने के कारण साथ में रुक जाते हैं
      फिर आखिर में कोई खास marketing/product push आ जाता है, special pricing logic को नए code और नए UI widget की जरूरत होती है, traffic और load बहुत बढ़ जाता है, और freeze के बावजूद उसे अभी तुरंत ship करना पड़ता है। Revenue से जुड़ा होने के कारण management के लिए वह important होता है
      ज्यादातर engineering teams और infra teams को इसकी खबर नहीं थी, क्योंकि product team आखिरी समय तक बहुत जोर लगा रही थी और कुछ हद तक secret में काम कर रही थी। नतीजा यह कि high-quality छोटे fixes तो freeze किए जा सकते हैं, लेकिन unstable नई features को ठीक से freeze नहीं कर पाते
      यह मुश्किल काम है, और फिर भी मेरी सलाह है कि freeze भूलकर पहले, बाद में और दौरान—हर समय—reasonable operations रखें और overdo न करें
    • थोड़ी देर की समस्या? 365 में Europe time के हिसाब से कल सुबह से ही चल रही outage है। एक बड़े bankruptcy मामले में information protect करने के लिए compliance tools इस्तेमाल कर रहा हूँ, इसलिए पता चला
    • तब तो developers बस freeze से पहले changes जल्दबाजी में push करेंगे
    • “freeze” का मतलब ठीक-ठीक क्या है? certificate renewal रोक देंगे? software security updates नहीं लेंगे?
      “unnecessary” changes को रोका जा सकता है, लेकिन उसकी सीमा बहुत जल्दी grey area बन जाती है

  • 2023 की शुरुआत वाली लगातार outages में भी Corrosion से जुड़ी तकलीफें थीं: https://community.fly.io/t/reliability-its-not-great/11253

    • अपना data store बनाने का फैसला शायद गलत दांव था
      constraints की मुझे बहुत अच्छी जानकारी नहीं है, लेकिन ScyllaDB eventual consistency support करता है और कुल मिलाकर काफी flexible है। multi-leader replication के लिए CouchDB भी एक विकल्प है