> ## Documentation Index
> Fetch the complete documentation index at: https://uncoded.ch/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Escalation — When to Reach Out for Help

> When self-help isn't enough, what to do next, how to gather context, and how to interact with support effectively.

<Info>
  **Escalation is the right move when self-help has been exhausted.** This page is the operator's escalation playbook: when to escalate, how to gather context, where to send your request, and how to set expectations for response.
</Info>

## When to escalate

<AccordionGroup>
  <Accordion title="✅ You've tried documented self-help and it didn't resolve" icon="check">
    You've checked:

    * The relevant documentation page.
    * Common issues catalog.
    * Error codes reference.
    * Connection problems guide.
    * The Dashboard's Logs panel.
    * The operator community.

    And the issue persists. Time to escalate.
  </Accordion>

  <Accordion title="✅ Suspected bug affecting your trading" icon="bug">
    Bot is doing something unexpected. You've ruled out configuration causes.

    **Action**: kill switch ON to reduce ongoing impact, then escalate with details.
  </Accordion>

  <Accordion title="✅ Confirmed security incident" icon="shield-halved">
    API key compromised, account suspicious activity, software vulnerability concern.

    **Action**: take protective steps first (revoke keys, change passwords), then escalate to support with details.
  </Accordion>

  <Accordion title="✅ Edge case not covered in documentation" icon="circle-question">
    Your scenario doesn't match standard patterns. Documentation doesn't directly answer.

    **Action**: escalate with a clear scenario description. The team can clarify or add docs for future operators.
  </Accordion>

  <Accordion title="✅ Commercial use case discussion" icon="briefcase">
    Considering managed-service offerings, fund structures, multi-tenant deployments. Different from individual operator use.

    **Action**: escalate to commercial inquiry channel. Different conversation than operational support.
  </Accordion>
</AccordionGroup>

## When NOT to escalate (yet)

<Warning>
  * ❌ **You haven't tried the obvious fixes.** Restart the container. Check the kill switch. Verify API key. Re-read the Logs panel. Most issues resolve at this layer.
  * ❌ **You haven't checked the documentation.** Most questions are answered there.
  * ❌ **You're asking trading advice.** Support clarifies how the product works; it can't tell you what trades to make.
  * ❌ **You're frustrated and want to vent.** Take a break. Frustration-driven support requests waste everyone's time.
  * ❌ **You haven't waited for transient issues to resolve.** Many problems self-resolve within minutes (network blip, brief venue outage).
</Warning>

## Pre-escalation checklist

Before sending your support request, gather:

<Steps>
  <Step title="Precise symptom description">
    Bad: "Bot isn't working." Good: "TradingBot stopped placing buy orders at `~14:30 UTC`. Existing positions continue managing normally. Sell rungs are filling. Only new buys halted."
  </Step>

  <Step title="When did it start">
    Approximate timestamp. Helps correlate with logs.
  </Step>

  <Step title="What changed recently">
    Update? Configuration change? VPS restart? New pair? Recent operator actions are often the cause.
  </Step>

  <Step title="What you've tried">
    "I've already tried: restart, kill switch ON, verified API key permissions, checked IP allowlist." Saves the support team from suggesting what you've done.
  </Step>

  <Step title="Relevant log excerpts">
    Copy the error messages from the Dashboard's Logs panel. Include surrounding context (5–10 lines).
  </Step>

  <Step title="Software version">
    Which TradingBot/Dashboard/SignalEditor version are you running?
  </Step>

  <Step title="Operational context">
    * Venue.
    * Mode and pair.
    * Capital.
    * Other relevant configuration.
  </Step>

  <Step title="What sensitive data NOT to include">
    Never include:

    * API keys.
    * API secrets.
    * Database passwords.
    * Telegram bot tokens.
    * Personal financial details beyond what's necessary.
  </Step>
</Steps>

## Where to escalate — the channels

<AccordionGroup>
  <Accordion title="Operator community (Discord / Telegram)" icon="users">
    **Use for**: questions where another operator has likely encountered the same thing. Configuration questions, venue quirks, routine troubleshooting.

    **Response time**: minutes to hours. Active community.

    **Best for**: 80% of operator questions resolve here without needing formal support.
  </Accordion>

  <Accordion title="Email support" icon="envelope">
    **Use for**: bugs, edge cases, sensitive issues, anything community can't or shouldn't handle.

    **Response time**: `24–72 hours` for non-urgent. Faster for confirmed bugs.

    **Best for**: documented issues that need direct unCoded team attention.
  </Accordion>

  <Accordion title="GitHub issues / public bug tracker" icon="github">
    **Use for**: confirmed reproducible bugs you're willing to discuss publicly.

    **Response time**: variable, depending on the bug's impact.

    **Best for**: bugs that benefit from public visibility (other operators may be affected).
  </Accordion>

  <Accordion title="Booked setup call" icon="phone">
    **Use for**: complex setup needs, new operators wanting hands-on guidance.

    **Response time**: scheduled (depends on availability).

    **Best for**: investments where live walkthrough is worth the time.
  </Accordion>

  <Accordion title="Commercial inquiries" icon="briefcase">
    **Use for**: managed-service offerings, fund structures, large-scale deployments.

    **Response time**: `1–5 business days`.

    **Best for**: non-individual-operator use cases.
  </Accordion>
</AccordionGroup>

## Severity levels — setting expectations

<AccordionGroup>
  <Accordion title="Critical — production-impacting bug" icon="bolt">
    **Definition**: confirmed bug actively affecting trading. Bot doing something wrong with real capital.

    **Expected response**: `4–24 hours` for first response.

    **Operator action**: engage kill switch while support investigates. Don't keep trading through a confirmed bug.
  </Accordion>

  <Accordion title="High — significant operational issue" icon="circle-exclamation">
    **Definition**: bot mostly working but a substantial feature broken. Or recurring error you can't resolve.

    **Expected response**: `24–48 hours` for first response.
  </Accordion>

  <Accordion title="Standard — typical operator question" icon="circle-question">
    **Definition**: configuration question, edge case, mild confusion.

    **Expected response**: `48–72 hours` for first response. Most reach within one business day.
  </Accordion>

  <Accordion title="Feature request" icon="sparkles">
    **Definition**: "it would be great if X."

    **Expected response**: acknowledged within a week. Implementation timeline depends on demand and design fit.

    **Note**: not all feature requests are accepted.
  </Accordion>

  <Accordion title="Commercial / partnership" icon="briefcase">
    **Definition**: business conversations beyond individual operator use.

    **Expected response**: `1–5 business days`.
  </Accordion>
</AccordionGroup>

## What good escalation looks like — example

<AccordionGroup>
  <Accordion title="The 'good' example" icon="check-double">
    Subject: TradingBot v2.4.0 — repeated `-2015` errors after Bybit IP allowlist update

    Body:

    ```text theme={null}
    Symptom: TradingBot keeps logging Bybit `10003` (auth invalid) errors every cycle since 14:30 UTC. Other venues (Binance) are fine. Existing positions on Bybit continue managing normally.

    What changed: I updated my Bybit API key's IP allowlist at 14:25 UTC because my VPS got a new IP after a provider migration this morning.

    What I've tried:
    - Verified VPS IP via `curl -s https://api.ipify.org` matches Bybit allowlist.
    - Waited 5 minutes after allowlist update.
    - Restarted TradingBot container.
    - Logged into Bybit web interface to confirm key still active and permissions correct.

    Versions: TradingBot v2.4.0, Dashboard v3.1.2.

    Logs (relevant excerpt):
    [...timestamps and error messages...]

    Anything I'm missing? Should the bot eventually pick up the new allowlist, or is there something else to check?
    ```

    Why this is good:

    * Precise symptom.
    * Timeline.
    * Recent changes documented.
    * What was tried documented.
    * Versions stated.
    * Relevant logs included.
    * Specific question at the end.

    Support can immediately suggest the right action without back-and-forth.
  </Accordion>

  <Accordion title="The 'bad' example" icon="ban">
    Subject: bot broken

    Body: bot stopped working please help

    Why this is bad:

    * No symptom detail.
    * No context.
    * No logs.
    * No what-was-tried.

    Support has to ask multiple clarifying questions before they can help. Resolution delayed by hours or days.
  </Accordion>
</AccordionGroup>

## After the support response

<Steps>
  <Step title="Read carefully">
    Support responses include actionable steps. Read fully before acting.
  </Step>

  <Step title="Try the suggested fix">
    In a controlled way — document what you do, observe results.
  </Step>

  <Step title="Report back if resolved">
    Helps the support team confirm. Also useful for future operators if the issue is documented.
  </Step>

  <Step title="Report back if not resolved">
    With what you tried, what happened, what's still going wrong. Iterative resolution.
  </Step>

  <Step title="Document the resolution in your operator log">
    For future-you. Include: what symptom, what cause, what fix.
  </Step>
</Steps>

## Best practices

<Tip>
  * ✅ **Self-help first** — most issues resolve before escalation.
  * ✅ **Gather context before escalating** — pre-escalation checklist.
  * ✅ **Choose the right channel** — community for routine, support for specific.
  * ✅ **Precise symptom description** — vague reports waste time.
  * ✅ **Include logs but not credentials** — never paste API keys.
  * ✅ **State what you've tried** — saves back-and-forth.
  * ✅ **Set realistic expectations** — `24–72 hours` for standard issues.
  * ✅ **Engage kill switch during investigation** — reduces ongoing risk.
  * ✅ **Report back on resolution** — helps the team and future operators.
  * ✅ **Document in operator log** — pattern recognition over time.
  * ✅ **Don't escalate routine questions** — community handles those faster.
  * ✅ **Don't escalate unsolvable problems** — trading advice, market predictions, lost funds.
</Tip>

## What's next

<CardGroup cols={2}>
  <Card title="Common issues" icon="circle-exclamation" href="/troubleshooting/common-issues">
    Self-help catalog.
  </Card>

  <Card title="Error codes" icon="bug" href="/troubleshooting/error-codes">
    Per-venue error reference.
  </Card>

  <Card title="Connection problems" icon="wifi" href="/troubleshooting/connection-problems">
    Connectivity-specific troubleshooting.
  </Card>

  <Card title="Support" icon="life-ring" href="/operations/support">
    The support channels and policies.
  </Card>

  <Card title="FAQ" icon="circle-question" href="/faq">
    Common operator questions.
  </Card>

  <Card title="Daily operations" icon="calendar-day" href="/operations/daily-operations">
    Routines that catch issues before escalation is needed.
  </Card>
</CardGroup>