🛟 The Help Desk · no dead ends

Say what you see. We’ll take it from there.

Describe what your Canary is doing. Every answer ends in a fix you do yourself, a practice run, or a handoff with the details attached. Nothing you type here leaves the page.

Start with the symptom

Type it the way you’d say it (“won’t turn on”, “blinking in threes”, “the port is busy”) or browse. The best match opens itself.

💡 The blink decoder

A Canary that can’t speak still tells you what’s wrong: the number of blinks in each group is the message. Count one group, pick it here.

🐤 Or let the device answer

Plug it in and let it tell you: health, crash evidence, update history, read in your browser. Nothing is uploaded, even when it fails.

🔌 Read my Canary — live

Plug it in over USB-C (a data cable), tap the button, pick the port. It reads the device’s self-manifest (board, firmware, self-reported health, the tamper flag), then listens while you tap RESET, so a crash or a brownout names itself.

🩺

Run the Doctor

The 10-probe self-test with a health score, feature demos, and the Bluetooth bring-up ladder.

Canary Doctor →

🖥️

Before you plug in

See exactly what should happen on your computer or phone — every OS, no hardware needed.

Plug-in emulator →

🧰

Bare or misbehaving board

The BOOT ritual, what the flasher checks before writing a byte, and the clean-install path.

Unflashed boards →

🔑

Recover or unseal

Rebuild it from its SD card, browse its read-only files, or open a sealed snapshot with your key.

Your Canary →

A failed self-test probe, decoded

Tap the probe that failed. The fixes come from the firmware’s own spec, in the same words the device and the Doctor use.

For makers: the same answers, over the wire

GET /api/selftest — the 10 probes, one JSON verdict; reachable even on the setup network.
GET /api/fleet — coarse presence + health for the fleet; deliberately address-free.
The serial console on Your Canary — live boot log, one-key commands, the signed self-manifest.
In safe mode, the crash evidence (reset reason + boot-stage breadcrumb) is already saved — the dashboard shows why, no serial cable needed.

🎛️ Practice on a fake one first

The Lab runs the real firmware, compiled for your browser. Its Fix-it flows walk the common repairs on an emulated Canary, and the bench lets you cause trouble on purpose (pull power mid-boot, brown it out, hold BOOT), then recover. Do the fix once where nothing is at stake.

🧪 Open the Lab 🖥️ Play the display modes

📦 If something is genuinely broken

The warranty is fix, not return: no fix asks you to mail anything back.

1️⃣Dead on arrival? Just tell us; no proof needed. Anything else: run the symptom entries above, and if the board still won’t answer, copy the flasher’s one-click diagnostic report. It holds only safe-to-share facts: no Wi-Fi secrets, no keys.

2️⃣Send it with your order email to the workshop. The report tells us which part actually failed.

3️⃣We ship the smallest thing that makes it right — a board in a mailer, a parts pack, or just the corrected unit — and you keep or recycle the original. A broken printed part often needs no shipment at all: every part is an open file you can print today.

Returns, what the warranty covers, and what it doesn’t: Terms of Sale.

Start a claim, assembled for you

Fill in what you know. The email opens in your own mail app; you press send.

🤝 Still stuck? Hand it to us

One button opens a pre-filled note with the page and the problem attached. Add a sentence; a maintainer reads every one.

📝 Open a pre-filled note ✉️ Email instead

Both buttons only compose the note; you press send. A GitHub note is public; email stays private and gets a human, usually within a few days.

Honesty note: the symptom catalog restates the firmware’s own diagnostics (the flasher’s error classifier, boot-log signatures, LED grammar and the self-test spec in onboarding-spec.json), pinned in CI. All open source on GitHub.