Does Jahez tell you when your restaurant goes offline?
Restaurant operators on Jahez get one real time banner about an interruption, and it is about the wrong thing. The portal dictionary carries the string “Streaming is paused temporarily”, in Arabic “تم إيقاف تحديث الطلبات”, and it refers to the order feed in the operations panel rather than to the branch. A branch that has been switched off, hidden, or penalised produces no equivalent banner. Jahez models availability across two separate axes and announces changes on neither of them.
What does Jahez itself publish about the way it contacts a restaurant?
One thing, and it is a security warning rather than a service promise. The portal carries the line “Jahez representatives will never ask you to open external links outside of the official restaurant portal or app to update your information”, rendered in Arabic as “لن يطلب منك ممثلو جاهز أبداً فتح روابط خارج البوابة الرسمية للمطعم أو التطبيق لتحديث معلوماتك.” Source: restaurant-portal.jahez.net.
That sentence is worth reading twice, because it defines the boundary of legitimate contact. Jahez is telling partners that anything real happens inside the official portal or app, and that a message arriving by another route should be treated as suspect.
It is a sensible policy and it has a consequence for this page. If real communication only happens inside the portal, then being informed requires being logged in, and a chain that discovers its branch is dark through an unexpected message has, by the platform’s own definition, received something it should not trust. There is no documented channel that reaches out.
Which interruption does the Jahez portal actually announce in real time?
The order feed, and only the order feed. The string OP_STREAMING_MESSAGE reads “Streaming is paused temporarily” in English and “تم إيقاف تحديث الطلبات” in Arabic, which translates as order updates having been stopped. It belongs to the operations panel where live orders arrive.
Confusing that with a branch level state is the most likely mistake on this platform, and it goes in the dangerous direction. A paused stream means the screen has stopped updating while the branch may be trading perfectly. A branch that has actually stopped trading produces no banner of its own at all.
What the branch controls produce instead is a receipt. Changing a status confirms with “The status has been update successful”, in Arabic “تم تحديث حاله الفرع”, typo included in the English. That message is rendered to the person who pressed the control. The branch list then carries the answer as columns, with “Open / Close” under “فتح / إغلاق” and “Visibility” under “حالة الظهور”, holding values including “Visible”, “Hidden”, “Partially Visible” and the preset “Invisible until Tomorrow”.
Who is the Jahez remote session banner written for?
The Jahez employee, not the restaurant. The dictionary contains REMOTE_SESSION_ACTIVE, reading “You are currently viewing restaurant ({{ restaurantId }}) as Jahez Employee.”, with the Arabic “أنت تتصفح حالياً مطعم ({{ restaurantId }}) كموظف جاهز.” The route it belongs to is named vendor-remote.
Grammatically and functionally that string addresses the person who is impersonating the account. It tells them whose portal they are inside. It is not a notice to the restaurant that somebody is in there.
For a chain this is the single most important asymmetry on Jahez. Platform staff have a documented, named way of operating inside a restaurant’s own back office, and the restaurant has no documented signal that a session took place or that anything was changed during it. Any change made that way arrives in the branch as a change of state with no author attached and no message.
Can a POS integration still carry a Jahez open or close instruction?
No, and this is a change rather than a gap. Deliverect, a certified integrator for the platform, states it plainly in its own help centre: “You want to open or close your store (busy mode) on Jahez. Deliverect can no longer open or close your store on Jahez. Any request to open or close your store must be made directly with Jahez, not through Deliverect.” Source: help.deliverect.com.
Closing the integration route closes it in both directions. There is no status to write and no status to read, which removes the one path by which a chain running middleware might have detected a change automatically. Availability on Jahez now lives entirely inside Jahez.
The visibility axis has the same shape and the same instruction. Deliverect’s guidance for a store that has vanished from the app is to ask: “Even when everything is set up correctly, your store may not show up on the Jahez app. Ask Jahez to set your store’s visibility status back to “Visible.”” Somebody has to notice first, and the noticing is unassisted.
Menu synchronisation runs on a clock rather than on a signal too. Foodics documents that “Jahez has an enabled auto sync everyday at 3 AM, If a manual sync is required please contact your Jahez Account Manager.” Source: help.foodics.com.
Where do Jahez penalties and rejections show up, and when?
In fields, waiting to be read. The portal dictionary contains PAST_PENALTY reading “Past Penalty” with the Arabic “غرامة سابقة”, and BLOCKED_DATE reading “Blocked Date” with “تاريخ الحظر”. Order rejections are typed by author, with customer_rejected reading “Customer Rejected” and jahez_rejected reading “Jahez Rejected”, alongside a “Rejection Reason” field.
A platform that distinguishes a rejection it made from one the customer made is a platform that has thought about attribution. Those distinctions live in a record, and a record is something you consult after the fact.
There is one place Jahez does warn before an action, and it is about the integration rather than the branch. Attempting to reissue partner credentials confirms with “Generating a new key will deactivate the previous one and may affect active integrations.”, in Arabic “إنشاء مفتاح جديد سيؤدي إلى إلغاء تفعيل المفتاح السابق وقد يؤثر على عمليات التكامل النشطة.” So the portal will stop somebody who is about to break their own connection, and it will not stop a branch from sitting hidden all day.
What does a ten hour average incident tell you about being told?
It answers the question this page asks better than any string does. Across our own monitoring of Jahez listings in Kuwait, branches were unavailable for 0.28 per cent of published trading time, a low share, with a mean interruption of ten hours thirty nine minutes, the longest of any platform we measure in any market.
Those two numbers together describe a specific pattern. Jahez branches do not go dark often, and when one does it tends to stay dark for something close to a whole trading day. A ten hour interruption is not a busy kitchen and it is not a thirty minute pause somebody forgot. It is a state nobody was informed about, on a platform where the integration route has been closed and the only announcement mechanism concerns the order stream.
The counter to that is a record built from outside, since there is nothing inside to subscribe to. Checking whether each branch can be ordered from right now, against the hours that branch published for today, catches a hidden branch, a busy state that outlived its duration and a change made during a remote session, all as one timestamped interval. That is what Kitchain (kitchain.co) collects on Jahez listings, and on this platform it is the only artefact that exists at all.