--- name: desk-monitoring description: How the desk watches markets and the account between trades using Grok Bot routines and WebSocket or polling watches - the desk brief, book checks, funding and price watches, alert conditions and what a watch may and may not do. Use when the user asks for briefings, alerts, "watch X" or scheduled checks. license: MIT metadata: version: "1.1.1" author: Galleon Labs category: desk ---

# Monitoring, briefs and watches

Monitoring is read-only. A watch may fetch, compute, save and alert. It may never send to the exchange. If a watch condition implies action ("stop got hit, re-enter"), the alert opens a proposal; the lifecycle does the rest.

## Grok Bot routines

Each Bot can own routines (schedules or event triggers). Ask the owning Bot to create one with: schedule and time zone, input source, expected result, approval boundary. Keep routines few and specific; the app keeps only recent run records, so a routine that produces something durable should also write to `/workspace/trading-desk`.

Recommended starting set (the user picks; none is on by default):

| Routine | Owner | Schedule | Output | | --- | --- | --- | --- | | Desk brief | Desk Lead | once a day at the user's chosen time | `briefs/YYYY-MM-DD-desk.md` and a short post | | Book check | Risk Manager | every 4-8 hours while positions are open | alert only if something changed or a limit is near | | Funding snapshot | Market Analyst | daily, or before the user's usual trading time | table of funding, OI, volume for the allowed markets | | Catalyst calendar refresh | Research Analyst | weekly | `research/calendar.md` | | Weekly review | Trade Reviewer | weekly | review posted by DM |

## The desk brief

Assembled by the Desk Lead from specialists' inputs, or generated by the Desk Lead directly if it is the only Bot awake:

``` DESK BRIEF | 2026-08-17 07:00 UTC | mainnet | account 0xabc...def markets (Market Analyst, allMids + metaAndAssetCtxs 06:58 UTC): BTC 97,120 (+0.8% 24h) | funding 0.0010%/h | OI $4.1B ETH 3,004 (+0.2%) | funding 0.0012%/h | OI $1.2B SOL 151.2 (-1.1%) | funding -0.0004%/h | OI $610M book (Risk Manager, clearinghouseState 06:59 UTC): 1 position, ETH long 0.4827 @ 3,000, uPnL +$1.9, margin ratio 4.6%, stop resting 2,900; open risk 0.5%; day PnL 0.0% research (Research Analyst): ETH client release scheduled 2026-08-19 [link]; nothing breaking on held markets open items: HG-20260816-01 live; no pending tickets ```

Facts with sources; interpretation, if any, on one clearly labelled line. No trade suggestions.

## Watches

A watch is a condition plus an alert. Two ways to run one on the desk computer:

- **Polling** with `/info` calls on a short loop from a script under `/workspace/trading-desk/watch/` (respect rate limits: `/info` requests carry weight; a poll every 5-15 seconds per market is plenty for a desk). - **WebSocket** subscriptions (`allMids`, `l2Book`, `trades`, `candle`, `userFills`, `orderUpdates`, `userEvents`) per `hyperliquid-websocket`. Better for fills and order updates. Keep the process supervised (a routine can restart it) and log to a file.

Common watch conditions:

| Watch | Data | Alert to | | --- | --- | --- | | Price crosses a level | `allMids` or `candle` | user, Desk Lead | | Funding flips sign or exceeds a threshold | `metaAndAssetCtxs` `funding` / `predictedFundings` | user, Desk Lead | | Order filled or cancelled | `orderUpdates`, `userFills` | Execution Trader, Trade Reviewer | | Margin ratio above X or liquidation distance below Y | `clearinghouseState` | user, Risk Manager, Desk Lead | | Position without a resting stop | `clearinghouseState` + `frontendOpenOrders` | Risk Manager, Desk Lead (incident) | | Daily loss stop approached (80%) or hit | `clearinghouseState` vs start-of-day equity | user, Risk Manager | | Exchange unreachable for more than N minutes | any `/info` call failing | Desk Lead |

An alert message carries: what fired, the value and the threshold, the source and UTC time, and the proposal id if related. Alerts do not include instructions to trade.

**Silence is not an all-clear.** A watch has three outcomes, never two: the condition fired, the condition did not fire, or the watch could not tell. A failed request, an empty response, a socket that reconnected and skipped messages, a candle that never closed, or data older than the watch's own interval is **unavailable**, and it must alert as such. A watch that quietly reports "not crossed" on a dead feed is the most dangerous thing on the desk, because it looks exactly like a calm market.

Give every watch a staleness bound (a small multiple of its interval) and check the age of each result against it. On unavailable: say which read failed, how old the last good value was, and how long the gap has run. Escalate a gap that outlives the bound, rather than waiting for the feed to come back.

## Hygiene

- Every watch script logs to `/workspace/trading-desk/watch/<name>.log` with UTC timestamps. - A watch that fails silently is worse than none: routines that own a watch check its heartbeat. - Do not run more than a few watches at once; each is a process on the shared computer. - When the desk goes flat and the user is done for the day, stop the watches that only make sense with positions.

## Never

- Never let a watch place, modify or cancel an order, or change leverage. Even a "protective" one. It alerts; the desk acts through a ticket. - Never alert with unsourced numbers. - Never report a stale or failed read as a condition that did not fire. That is an `unavailable` alert, not silence. - Never poll faster than the desk needs; a rate-limited desk is a blind desk.

--- name: desk-monitoring description: How the desk watches markets and the account between trades using Grok Bot routines and WebSocket or polling watches - the desk brief, book checks, funding and price watches, alert conditions and what a watch may and may not do. Use when the user asks for briefings, alerts, "watch X" or scheduled checks. license: MIT metadata: version: "1.1.1" author: Galleon Labs category: desk ---

# Monitoring, briefs and watches

Monitoring is read-only. A watch may fetch, compute, save and alert. It may never send to the exchange. If a watch condition implies action ("stop got hit, re-enter"), the alert opens a proposal; the lifecycle does the rest.

## Grok Bot routines

Each Bot can own routines (schedules or event triggers). Ask the owning Bot to create one with: schedule and time zone, input source, expected result, approval boundary. Keep routines few and specific; the app keeps only recent run records, so a routine that produces something durable should also write to `/workspace/trading-desk`.

Recommended starting set (the user picks; none is on by default):

| Routine | Owner | Schedule | Output | | --- | --- | --- | --- | | Desk brief | Desk Lead | once a day at the user's chosen time | `briefs/YYYY-MM-DD-desk.md` and a short post | | Book check | Risk Manager | every 4-8 hours while positions are open | alert only if something changed or a limit is near | | Funding snapshot | Market Analyst | daily, or before the user's usual trading time | table of funding, OI, volume for the allowed markets | | Catalyst calendar refresh | Research Analyst | weekly | `research/calendar.md` | | Weekly review | Trade Reviewer | weekly | review posted by DM |

## The desk brief

Assembled by the Desk Lead from specialists' inputs, or generated by the Desk Lead directly if it is the only Bot awake:

``` DESK BRIEF | 2026-08-17 07:00 UTC | mainnet | account 0xabc...def markets (Market Analyst, allMids + metaAndAssetCtxs 06:58 UTC): BTC 97,120 (+0.8% 24h) | funding 0.0010%/h | OI $4.1B ETH 3,004 (+0.2%) | funding 0.0012%/h | OI $1.2B SOL 151.2 (-1.1%) | funding -0.0004%/h | OI $610M book (Risk Manager, clearinghouseState 06:59 UTC): 1 position, ETH long 0.4827 @ 3,000, uPnL +$1.9, margin ratio 4.6%, stop resting 2,900; open risk 0.5%; day PnL 0.0% research (Research Analyst): ETH client release scheduled 2026-08-19 [link]; nothing breaking on held markets open items: HG-20260816-01 live; no pending tickets ```

Facts with sources; interpretation, if any, on one clearly labelled line. No trade suggestions.

## Watches

A watch is a condition plus an alert. Two ways to run one on the desk computer:

- **Polling** with `/info` calls on a short loop from a script under `/workspace/trading-desk/watch/` (respect rate limits: `/info` requests carry weight; a poll every 5-15 seconds per market is plenty for a desk). - **WebSocket** subscriptions (`allMids`, `l2Book`, `trades`, `candle`, `userFills`, `orderUpdates`, `userEvents`) per `hyperliquid-websocket`. Better for fills and order updates. Keep the process supervised (a routine can restart it) and log to a file.

Common watch conditions:

| Watch | Data | Alert to | | --- | --- | --- | | Price crosses a level | `allMids` or `candle` | user, Desk Lead | | Funding flips sign or exceeds a threshold | `metaAndAssetCtxs` `funding` / `predictedFundings` | user, Desk Lead | | Order filled or cancelled | `orderUpdates`, `userFills` | Execution Trader, Trade Reviewer | | Margin ratio above X or liquidation distance below Y | `clearinghouseState` | user, Risk Manager, Desk Lead | | Position without a resting stop | `clearinghouseState` + `frontendOpenOrders` | Risk Manager, Desk Lead (incident) | | Daily loss stop approached (80%) or hit | `clearinghouseState` vs start-of-day equity | user, Risk Manager | | Exchange unreachable for more than N minutes | any `/info` call failing | Desk Lead |

An alert message carries: what fired, the value and the threshold, the source and UTC time, and the proposal id if related. Alerts do not include instructions to trade.

**Silence is not an all-clear.** A watch has three outcomes, never two: the condition fired, the condition did not fire, or the watch could not tell. A failed request, an empty response, a socket that reconnected and skipped messages, a candle that never closed, or data older than the watch's own interval is **unavailable**, and it must alert as such. A watch that quietly reports "not crossed" on a dead feed is the most dangerous thing on the desk, because it looks exactly like a calm market.

Give every watch a staleness bound (a small multiple of its interval) and check the age of each result against it. On unavailable: say which read failed, how old the last good value was, and how long the gap has run. Escalate a gap that outlives the bound, rather than waiting for the feed to come back.

## Hygiene

- Every watch script logs to `/workspace/trading-desk/watch/<name>.log` with UTC timestamps. - A watch that fails silently is worse than none: routines that own a watch check its heartbeat. - Do not run more than a few watches at once; each is a process on the shared computer. - When the desk goes flat and the user is done for the day, stop the watches that only make sense with positions.

## Never

- Never let a watch place, modify or cancel an order, or change leverage. Even a "protective" one. It alerts; the desk acts through a ticket. - Never alert with unsourced numbers. - Never report a stale or failed read as a condition that did not fire. That is an `unavailable` alert, not silence. - Never poll faster than the desk needs; a rate-limited desk is a blind desk.

--- name: desk-monitoring description: How the desk watches markets and the account between trades using Grok Bot routines and WebSocket or polling watches - the desk brief, book checks, funding and price watches, alert conditions and what a watch may and may not do. Use when the user asks for briefings, alerts, "watch X" or scheduled checks. license: MIT metadata: version: "1.1.1" author: Galleon Labs category: desk ---

# Monitoring, briefs and watches

Monitoring is read-only. A watch may fetch, compute, save and alert. It may never send to the exchange. If a watch condition implies action ("stop got hit, re-enter"), the alert opens a proposal; the lifecycle does the rest.

## Grok Bot routines

Each Bot can own routines (schedules or event triggers). Ask the owning Bot to create one with: schedule and time zone, input source, expected result, approval boundary. Keep routines few and specific; the app keeps only recent run records, so a routine that produces something durable should also write to `/workspace/trading-desk`.

Recommended starting set (the user picks; none is on by default):

| Routine | Owner | Schedule | Output | | --- | --- | --- | --- | | Desk brief | Desk Lead | once a day at the user's chosen time | `briefs/YYYY-MM-DD-desk.md` and a short post | | Book check | Risk Manager | every 4-8 hours while positions are open | alert only if something changed or a limit is near | | Funding snapshot | Market Analyst | daily, or before the user's usual trading time | table of funding, OI, volume for the allowed markets | | Catalyst calendar refresh | Research Analyst | weekly | `research/calendar.md` | | Weekly review | Trade Reviewer | weekly | review posted by DM |

## The desk brief

Assembled by the Desk Lead from specialists' inputs, or generated by the Desk Lead directly if it is the only Bot awake:

``` DESK BRIEF | 2026-08-17 07:00 UTC | mainnet | account 0xabc...def markets (Market Analyst, allMids + metaAndAssetCtxs 06:58 UTC): BTC 97,120 (+0.8% 24h) | funding 0.0010%/h | OI $4.1B ETH 3,004 (+0.2%) | funding 0.0012%/h | OI $1.2B SOL 151.2 (-1.1%) | funding -0.0004%/h | OI $610M book (Risk Manager, clearinghouseState 06:59 UTC): 1 position, ETH long 0.4827 @ 3,000, uPnL +$1.9, margin ratio 4.6%, stop resting 2,900; open risk 0.5%; day PnL 0.0% research (Research Analyst): ETH client release scheduled 2026-08-19 [link]; nothing breaking on held markets open items: HG-20260816-01 live; no pending tickets ```

Facts with sources; interpretation, if any, on one clearly labelled line. No trade suggestions.

## Watches

A watch is a condition plus an alert. Two ways to run one on the desk computer:

- **Polling** with `/info` calls on a short loop from a script under `/workspace/trading-desk/watch/` (respect rate limits: `/info` requests carry weight; a poll every 5-15 seconds per market is plenty for a desk). - **WebSocket** subscriptions (`allMids`, `l2Book`, `trades`, `candle`, `userFills`, `orderUpdates`, `userEvents`) per `hyperliquid-websocket`. Better for fills and order updates. Keep the process supervised (a routine can restart it) and log to a file.

Common watch conditions:

| Watch | Data | Alert to | | --- | --- | --- | | Price crosses a level | `allMids` or `candle` | user, Desk Lead | | Funding flips sign or exceeds a threshold | `metaAndAssetCtxs` `funding` / `predictedFundings` | user, Desk Lead | | Order filled or cancelled | `orderUpdates`, `userFills` | Execution Trader, Trade Reviewer | | Margin ratio above X or liquidation distance below Y | `clearinghouseState` | user, Risk Manager, Desk Lead | | Position without a resting stop | `clearinghouseState` + `frontendOpenOrders` | Risk Manager, Desk Lead (incident) | | Daily loss stop approached (80%) or hit | `clearinghouseState` vs start-of-day equity | user, Risk Manager | | Exchange unreachable for more than N minutes | any `/info` call failing | Desk Lead |

An alert message carries: what fired, the value and the threshold, the source and UTC time, and the proposal id if related. Alerts do not include instructions to trade.

**Silence is not an all-clear.** A watch has three outcomes, never two: the condition fired, the condition did not fire, or the watch could not tell. A failed request, an empty response, a socket that reconnected and skipped messages, a candle that never closed, or data older than the watch's own interval is **unavailable**, and it must alert as such. A watch that quietly reports "not crossed" on a dead feed is the most dangerous thing on the desk, because it looks exactly like a calm market.

Give every watch a staleness bound (a small multiple of its interval) and check the age of each result against it. On unavailable: say which read failed, how old the last good value was, and how long the gap has run. Escalate a gap that outlives the bound, rather than waiting for the feed to come back.

## Hygiene

- Every watch script logs to `/workspace/trading-desk/watch/<name>.log` with UTC timestamps. - A watch that fails silently is worse than none: routines that own a watch check its heartbeat. - Do not run more than a few watches at once; each is a process on the shared computer. - When the desk goes flat and the user is done for the day, stop the watches that only make sense with positions.

## Never

- Never let a watch place, modify or cancel an order, or change leverage. Even a "protective" one. It alerts; the desk acts through a ticket. - Never alert with unsourced numbers. - Never report a stale or failed read as a condition that did not fire. That is an `unavailable` alert, not silence. - Never poll faster than the desk needs; a rate-limited desk is a blind desk.

--- name: desk-monitoring description: How the desk watches markets and the account between trades using Grok Bot routines and WebSocket or polling watches - the desk brief, book checks, funding and price watches, alert conditions and what a watch may and may not do. Use when the user asks for briefings, alerts, "watch X" or scheduled checks. license: MIT metadata: version: "1.1.1" author: Galleon Labs category: desk ---

# Monitoring, briefs and watches

Monitoring is read-only. A watch may fetch, compute, save and alert. It may never send to the exchange. If a watch condition implies action ("stop got hit, re-enter"), the alert opens a proposal; the lifecycle does the rest.

## Grok Bot routines

Each Bot can own routines (schedules or event triggers). Ask the owning Bot to create one with: schedule and time zone, input source, expected result, approval boundary. Keep routines few and specific; the app keeps only recent run records, so a routine that produces something durable should also write to `/workspace/trading-desk`.

Recommended starting set (the user picks; none is on by default):

| Routine | Owner | Schedule | Output | | --- | --- | --- | --- | | Desk brief | Desk Lead | once a day at the user's chosen time | `briefs/YYYY-MM-DD-desk.md` and a short post | | Book check | Risk Manager | every 4-8 hours while positions are open | alert only if something changed or a limit is near | | Funding snapshot | Market Analyst | daily, or before the user's usual trading time | table of funding, OI, volume for the allowed markets | | Catalyst calendar refresh | Research Analyst | weekly | `research/calendar.md` | | Weekly review | Trade Reviewer | weekly | review posted by DM |

## The desk brief

Assembled by the Desk Lead from specialists' inputs, or generated by the Desk Lead directly if it is the only Bot awake:

``` DESK BRIEF | 2026-08-17 07:00 UTC | mainnet | account 0xabc...def markets (Market Analyst, allMids + metaAndAssetCtxs 06:58 UTC): BTC 97,120 (+0.8% 24h) | funding 0.0010%/h | OI $4.1B ETH 3,004 (+0.2%) | funding 0.0012%/h | OI $1.2B SOL 151.2 (-1.1%) | funding -0.0004%/h | OI $610M book (Risk Manager, clearinghouseState 06:59 UTC): 1 position, ETH long 0.4827 @ 3,000, uPnL +$1.9, margin ratio 4.6%, stop resting 2,900; open risk 0.5%; day PnL 0.0% research (Research Analyst): ETH client release scheduled 2026-08-19 [link]; nothing breaking on held markets open items: HG-20260816-01 live; no pending tickets ```

Facts with sources; interpretation, if any, on one clearly labelled line. No trade suggestions.

## Watches

A watch is a condition plus an alert. Two ways to run one on the desk computer:

- **Polling** with `/info` calls on a short loop from a script under `/workspace/trading-desk/watch/` (respect rate limits: `/info` requests carry weight; a poll every 5-15 seconds per market is plenty for a desk). - **WebSocket** subscriptions (`allMids`, `l2Book`, `trades`, `candle`, `userFills`, `orderUpdates`, `userEvents`) per `hyperliquid-websocket`. Better for fills and order updates. Keep the process supervised (a routine can restart it) and log to a file.

Common watch conditions:

| Watch | Data | Alert to | | --- | --- | --- | | Price crosses a level | `allMids` or `candle` | user, Desk Lead | | Funding flips sign or exceeds a threshold | `metaAndAssetCtxs` `funding` / `predictedFundings` | user, Desk Lead | | Order filled or cancelled | `orderUpdates`, `userFills` | Execution Trader, Trade Reviewer | | Margin ratio above X or liquidation distance below Y | `clearinghouseState` | user, Risk Manager, Desk Lead | | Position without a resting stop | `clearinghouseState` + `frontendOpenOrders` | Risk Manager, Desk Lead (incident) | | Daily loss stop approached (80%) or hit | `clearinghouseState` vs start-of-day equity | user, Risk Manager | | Exchange unreachable for more than N minutes | any `/info` call failing | Desk Lead |

An alert message carries: what fired, the value and the threshold, the source and UTC time, and the proposal id if related. Alerts do not include instructions to trade.

**Silence is not an all-clear.** A watch has three outcomes, never two: the condition fired, the condition did not fire, or the watch could not tell. A failed request, an empty response, a socket that reconnected and skipped messages, a candle that never closed, or data older than the watch's own interval is **unavailable**, and it must alert as such. A watch that quietly reports "not crossed" on a dead feed is the most dangerous thing on the desk, because it looks exactly like a calm market.

Give every watch a staleness bound (a small multiple of its interval) and check the age of each result against it. On unavailable: say which read failed, how old the last good value was, and how long the gap has run. Escalate a gap that outlives the bound, rather than waiting for the feed to come back.

## Hygiene

- Every watch script logs to `/workspace/trading-desk/watch/<name>.log` with UTC timestamps. - A watch that fails silently is worse than none: routines that own a watch check its heartbeat. - Do not run more than a few watches at once; each is a process on the shared computer. - When the desk goes flat and the user is done for the day, stop the watches that only make sense with positions.

## Never

- Never let a watch place, modify or cancel an order, or change leverage. Even a "protective" one. It alerts; the desk acts through a ticket. - Never alert with unsourced numbers. - Never report a stale or failed read as a condition that did not fire. That is an `unavailable` alert, not silence. - Never poll faster than the desk needs; a rate-limited desk is a blind desk.