Skip to main content

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 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.

​
When to escalate

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.
Bot is doing something unexpected. You’ve ruled out configuration causes.Action: kill switch ON to reduce ongoing impact, then escalate with details.
API key compromised, account suspicious activity, software vulnerability concern.Action: take protective steps first (revoke keys, change passwords), then escalate to support with details.
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.
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.

​
When NOT to escalate (yet)

  • ❌ 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).

​
Pre-escalation checklist

Before sending your support request, gather:
1

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.”
2

When did it start

Approximate timestamp. Helps correlate with logs.
3

What changed recently

Update? Configuration change? VPS restart? New pair? Recent operator actions are often the cause.
4

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.
5

Relevant log excerpts

Copy the error messages from the Dashboard’s Logs panel. Include surrounding context (5–10 lines).
6

Software version

Which TradingBot/Dashboard/SignalEditor version are you running?
7

Operational context

  • Venue.
  • Mode and pair.
  • Capital.
  • Other relevant configuration.
8

What sensitive data NOT to include

Never include:
  • API keys.
  • API secrets.
  • Database passwords.
  • Telegram bot tokens.
  • Personal financial details beyond what’s necessary.

​
Where to escalate — the channels

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.
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.
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).
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.
Use for: managed-service offerings, fund structures, large-scale deployments.Response time: 1–5 business days.Best for: non-individual-operator use cases.

​
Severity levels — setting expectations

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.
Definition: bot mostly working but a substantial feature broken. Or recurring error you can’t resolve.Expected response: 24–48 hours for first response.
Definition: configuration question, edge case, mild confusion.Expected response: 48–72 hours for first response. Most reach within one business day.
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.
Definition: business conversations beyond individual operator use.Expected response: 1–5 business days.

​
What good escalation looks like — example

Subject: TradingBot v2.4.0 — repeated -2015 errors after Bybit IP allowlist updateBody:
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.
Subject: bot brokenBody: bot stopped working please helpWhy 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.

​
After the support response

1

Read carefully

Support responses include actionable steps. Read fully before acting.
2

Try the suggested fix

In a controlled way — document what you do, observe results.
3

Report back if resolved

Helps the support team confirm. Also useful for future operators if the issue is documented.
4

Report back if not resolved

With what you tried, what happened, what’s still going wrong. Iterative resolution.
5

Document the resolution in your operator log

For future-you. Include: what symptom, what cause, what fix.

​
Best practices

  • ✅ 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.

​
What’s next

Common issues

Self-help catalog.

Error codes

Per-venue error reference.

Connection problems

Connectivity-specific troubleshooting.

Support

The support channels and policies.

FAQ

Common operator questions.

Daily operations

Routines that catch issues before escalation is needed.
Last modified on May 3, 2026