# स्टोर हेल्थ

v1.10.0 में नया

स्टोर हेल्थ **WCPOS v1.10.0** में पेश किया गया है। यह पुरानी अलग लॉग्स स्क्रीन की जगह लेता है और सिंकिंग, लोकल डेटा कवरेज तथा सर्वर भार पर सजीव दृश्यता जोड़ता है।

**स्टोर हेल्थ** POS का वह डैशबोर्ड है जो आपके डिवाइस और आपके WooCommerce स्टोर के बीच हो रही हर चीज़ दिखाता है। इसे नेविगेशन ड्रॉअर से खोलें (हार्ट-पल्स आइकॉन)। इसमें तीन टैब हैं: **प्रदर्शन**, **डेटाबेस**, और **लॉग्स**।

## प्रदर्शन[​](#performance "प्रदर्शन के लिए सीधा लिंक")

प्रदर्शन टैब इस सवाल का जवाब देता है कि "POS मेरे सर्वर पर कितना खर्च डाल रहा है, और क्या सिंकिंग स्वस्थ है?"

* **स्थिति पंक्ति** — इंजन की वर्तमान स्थिति के आधार पर `✓ सामान्य` या `⚠ ध्यान चाहिए` (जो गड़बड़ी पहले ही ठीक हो चुकी है, वह आपको पूरे दिन नहीं कोसेगी)।
* **मापी गई गतिविधि** — पिछले 24 घंटों में किए गए अनुरोध और सामान्य प्रतिक्रिया समय अनुमान नहीं, बल्कि इसी काउंटर की मापें हैं। स्थानांतरित डेटा एक न्यूनतम सीमा है, क्योंकि जिन प्रतिक्रियाओं में आकार घोषित नहीं होता वे शून्य जोड़ती हैं।
* **अपटाइम पट्टी** — पिछले 24 घंटों के लिए प्रति घंटा एक खाना। हरा मतलब उस घंटे अनुरोध बिना त्रुटि के पूरे हुए; एम्बर मतलब कम से कम एक अनुरोध विफल हुआ (एक भी — कोई सीमा नहीं है); खाली मतलब ऐप चल ही नहीं रहा था।
* **अगली जाँच का काउंटडाउन** — अगली परिवर्तन जाँच कब होनी है। निष्क्रिय काउंटर पर यह वाजिब रूप से कॉन्फ़िगर किए गए अंतराल से लंबा दिख सकता है, क्योंकि जाँचों में जिटर होता है और 10 मिनट की निष्क्रियता के बाद वे धीमी हो जाती हैं। शांत काउंटर पर लंबा काउंटडाउन सामान्य है, अटका हुआ सिंक नहीं।

### सिंक प्रीसेट[​](#sync-presets "सिंक प्रीसेट के लिए सीधा लिंक")

तीन प्रीसेट कार्ड दो डायल के ज़रिए तय करते हैं कि यह डिवाइस कितनी तत्परता से सिंक करे — POS कितनी बार परिवर्तनों की जाँच करे, और एक बार में कितने रिकॉर्ड माँगे:

| प्रीसेट                 | जाँच अंतराल | प्रति अनुरोध रिकॉर्ड |
| ----------------------- | ----------- | -------------------- |
| **Eco**                 | 5 मिनट      | 25                   |
| **Balanced** (डिफ़ॉल्ट) | 60 से       | 50                   |
| **Realtime**            | 10 से       | 75                   |

साझा या किफ़ायती होस्टिंग के लिए **Eco** चुनें, और **Realtime** तब जब कई काउंटरों को एक-दूसरे के परिवर्तन जल्दी दिखने चाहिए और सर्वर इसे झेल सकता हो। **Custom** स्लाइडर पूरी सीमा खोल देते हैं (5 सेकंड–5 मिनट, 10–100 रिकॉर्ड)।

दो बातें जान लें:

* **सेटिंग्स प्रति डिवाइस होती हैं।** एक काउंटर को समायोजित करने से बाकी हर डिवाइस अपरिवर्तित रहता है — जिस-जिस काउंटर को बदलना हो, वहाँ बदलाव दोहराएँ।
* डायल के बगल में दिखने वाला *\~N अनुरोध प्रतिदिन* आँकड़ा कॉन्फ़िगर किए गए अंतराल से निकाली गई एक नाममात्र जाँच दर है, कोई अधिकतम सीमा या भविष्यवाणी नहीं। जिटर वास्तविक गिनती को किसी भी दिशा में खिसका सकता है; बिना बदलाव वाला `304` कम खर्चीला होता है पर गिना फिर भी एक अनुरोध ही जाता है। निष्क्रियता क्षय गिनती को केवल उन प्रीसेट के लिए घटाता है जो उसकी 60-सेकंड की न्यूनतम सीमा से तेज़ हैं, इसलिए यह Balanced को और धीमा नहीं करता।

बदलाव तुरंत लागू होते हैं; पुनः आरंभ की ज़रूरत नहीं। इन आँकड़ों के पीछे की इंजीनियरिंग के लिए देखें [सिंक प्रदर्शन](/hi-IN/reference/sync-performance.md)।

## डेटाबेस[​](#database "डेटाबेस के लिए सीधा लिंक")

डेटाबेस टैब इस सवाल का जवाब देता है कि "इस डिवाइस पर क्या है, और क्या सब कुछ मेरे सर्वर तक पहुँचा?"

सबसे ऊपर चार टाइलें: **बिक्री के लिए तैयार** पड़ाव, इस डिवाइस पर मौजूद रिकॉर्ड, उपयोग में लिया गया स्टोरेज, और भेजे जाने की प्रतीक्षा कर रहे परिवर्तन।

बिक्री के लिए तैयार एक पड़ाव है, पूरे डाउनलोड का द्वार नहीं

यह पहला उत्पाद डिवाइस पर आते ही चालू हो जाता है। ऑफ़लाइन होना इसे नहीं रोकता — जिस काउंटर पर उत्पाद मौजूद हैं, वह ऑफ़लाइन बेचने के लिए तैयार है। लोकल-फ़र्स्ट POS का मकसद यही है।

### कवरेज तालिका[​](#coverage "कवरेज तालिका के लिए सीधा लिंक")

हर सिंक किए गए संग्रह को एक पंक्ति मिलती है: **डिवाइस पर**, **सर्वर पर**, और एक कवरेज बार। ये संख्याएँ एक सख़्त ईमानदारी नियम का पालन करती हैं — *सर्वर पर* वाला कुल सर्वर द्वारा बताया गया वास्तविक आँकड़ा होता है, कभी अनुमान नहीं:

* ***जाँचा जा रहा है…*** — POS के पास अभी ताज़ा सर्वर कुल नहीं है। यदि कोई पंक्ति लगभग 15 मिनट से अधिक इसी हाल में रहे, तो उस संग्रह का REST रूट विफल हो रहा हो सकता है; [लॉग्स](#logs) देखें।
* **आंशिक बार अक्सर सामान्य होता है।** ग्राहक निष्क्रिय समय में धीरे-धीरे डाउनलोड होते हैं, श्रेणियाँ और कूपन पहली बार खोले जाने पर डाउनलोड होते हैं, और **ऑर्डर** बार आपके पूरे ऑर्डर इतिहास के सापेक्ष मापता है जबकि काउंटर जानबूझकर केवल खुले और हालिया ऑर्डर रखता है — इसलिए पूरी तरह स्वस्थ काउंटर पर भी ऑर्डर आंशिक दिखते हैं।
* **"साफ़ करें और दोबारा डाउनलोड करें" के बाद खाली या कम गिनती डिज़ाइन का ही नतीजा है, अटका हुआ सिंक नहीं** — जो संग्रह माँग पर डाउनलोड होते हैं वे उपयोग के साथ फिर भर जाते हैं, और हर पंक्ति का विवरण बताता है कि वह संग्रह कैसे भरता है।

### ऐसे परिवर्तन जो कभी आपके सर्वर तक नहीं पहुँचे[​](#refused-changes "ऐसे परिवर्तन जो कभी आपके सर्वर तक नहीं पहुँचे के लिए सीधा लिंक")

यदि आपका सर्वर किसी परिवर्तन को स्थायी रूप से अस्वीकार कर देता है (उदाहरण के लिए, ऐसी बिक्री जो तब बनी जब साइट ने अनुरोध को अमान्य बताकर ठुकरा दिया), तो POS उसे चुपचाप हमेशा दोबारा **नहीं** आज़माता, और न ही उसे छिपाता है। परिवर्तन को अलग रखकर यहाँ सूचीबद्ध किया जाता है — सर्वर के अपने कारण के साथ, यह भी कि वह कब हुआ, और दो क्रियाओं के साथ:

* **दोबारा भेजें** — रिकॉर्ड की *मौजूदा* स्थिति से अनुरोध दोबारा बनाता है और उसे फिर कतार में डालता है। यदि वही फ़ील्ड दोबारा अस्वीकार होती है, तो सफलता का दिखावा करने के बजाय प्रयासों की गिनती स्पष्ट रूप से बढ़ जाती है।
* **हटाएँ** — परिवर्तन को छोड़ देता है। पुष्टिकरण डायलॉग ठीक-ठीक बताता है कि उस रिकॉर्ड के लिए हटाने का क्या मतलब है (उस स्थिति सहित जब रिकॉर्ड कभी केवल इसी डिवाइस पर मौजूद था, जहाँ हटाने से वह मिट जाता है)।

रिकवरी हमेशा एक सोच-समझकर की गई, दृश्यमान क्रिया होती है — यहाँ कुछ भी स्वचालित नहीं है।

### साफ़ करें और दोबारा डाउनलोड करें[​](#clear-and-redownload "साफ़ करें और दोबारा डाउनलोड करें के लिए सीधा लिंक")

हर संग्रह पंक्ति पर **साफ़ करें और दोबारा डाउनलोड करें** उपलब्ध है, जो उस संग्रह की लोकल प्रति हटाकर उसे दोबारा लाता है। पुष्टिकरण बताता है कि कितने रिकॉर्ड और लगभग कितना स्टोरेज हटेगा, और सर्वर पर सुरक्षित रूप से क्या बना रहेगा। सारा लोकल डेटा साफ़ करने के बजाय इसे चुनें — यह लक्षित है और आपको लॉग आउट नहीं करता। पूर्ण रीसेट के लिए [सारा लोकल डेटा साफ़ करें](/hi-IN/support/troubleshooting/clear-local-data.md) मौजूद है।

## लॉग्स[​](#logs "लॉग्स के लिए सीधा लिंक")

लॉग्स टैब इस डिवाइस पर हुई सिंक गतिविधि का बही-खाता है: प्रति पंक्ति **समय, स्तर, इवेंट, अवधि, स्थिति**, जो 30 दिनों तक रखा जाता है।

* **प्रीसेट फ़िल्टर** — सभी / क्रियाएँ / त्रुटियाँ / सिंक, साथ ही एक **विस्तृत डायग्नोस्टिक्स** टॉगल जो 24 घंटों तक अतिरिक्त विवरण दर्ज करता है और फिर स्वयं बंद हो जाता है।
* **पंक्ति विवरण** — त्रुटियाँ और चेतावनियाँ विस्तृत होकर सरल भाषा में कारण, एक डेटा-सुरक्षा पंक्ति, एक सुझाया गया अगला कदम, और [त्रुटि कोड](/hi-IN/error-codes/.md) के लिए एक सहायता लिंक दिखाती हैं। हर विवरण दृश्य में एक कॉपी करने योग्य इवेंट कोड होता है — सपोर्ट से संपर्क करते समय उसका उल्लेख करें।
* लॉग प्रविष्टियाँ दिखाते समय अनूदित की जाती हैं, इसलिए महीनों पहले लिखी गई पंक्ति उसी भाषा में पढ़ी जाती है जिसमें काउंटर आज चल रहा है; स्थिर पहचानकर्ता इवेंट कोड है।

दो टैब, दो गिनतियाँ

लॉग्स टैब अपनी अटके हुए रिकॉर्ड की गिनती केवल लॉग प्रविष्टियों से निकालता है; डेटाबेस टैब अलग रखे गए अस्वीकृत परिवर्तनों को भी शामिल करता है। जब दोनों में अंतर हो, तो आपके सर्वर तक क्या नहीं पहुँचा, इस पर **डेटाबेस ही प्रामाणिक है**।

## संबंधित पेज[​](#related "संबंधित पेज के लिए सीधा लिंक")

* [सिंक इंजन कैसे काम करता है](/hi-IN/reference/sync-engine.md) — लेन, परिवर्तन पहचान और राइट कतार पर डेवलपर-स्तरीय विवरण
* [सिंक प्रदर्शन](/hi-IN/reference/sync-performance.md) — आपके सर्वर की रक्षा करने वाली अनुरोध सीमाएँ और बैक-ऑफ़ नियम
* [सर्वर प्रदर्शन](/hi-IN/support/performance/server.md) — WordPress/WooCommerce होस्टिंग की ट्यूनिंग
* [सारा लोकल डेटा साफ़ करें](/hi-IN/support/troubleshooting/clear-local-data.md) — पूर्ण लोकल रीसेट