Support

How support works

Bobbin is built and run by one person, and the support model says so rather than pretending otherwise. It is designed so that most of what you need is answered without waiting for anyone:

1. The console tells you first. The notification bell carries every problem Bobbin knows about — a grant that has gone missing, a Slack connection that was removed, a plan that has lapsed — with the action that fixes it. “Check again” on a project re-verifies access on demand.
2. These docs are the manual. Every grant path, every state a project can be in, every card block, and what “inconclusive” means are written here, and written so an assistant can follow them for you.
3. Email is for what those two cannot answer.

Email

support@getbobbin.dev — for a question about a grant, a report that looks wrong, a billing query, or “why do you need this role”.

What to expect, honestly:

• Questions and requests: a reply within one UK working day (Monday to Friday, 09:00–17:30 London time).
• Bobby has stopped investigating for your workspace: acknowledged within four working hours, and either fixed or explained by the end of the next working day. Say “not investigating” in the subject line and it is read first.
• Security concerns: acknowledged within four working hours, any day. Email the same address.

There is no phone line and no 24/7 rota. If you need a contractual SLA beyond this, say so when you get in touch; it is priced separately and is not something a one-person company will promise lightly.

Status

A status page at status.getbobbin.dev is planned. Until it exists, an outage on our side reaches you as an email from the address above, and the notification bell in the console says when Bobbin itself could not investigate.

What to include in a report

The faster we can reproduce what you are seeing, the faster we can answer. Where you have it, include:

• Your workspace or tenant id, visible in the console.
• The project id involved, if the report is about a specific investigation or a grant.
• What you expected versus what happened — for a grant issue, the exact pill text from Verify access; for a report you think is wrong, a link to the Slack thread or the console’s investigation record.
• When it happened, in your own timezone plus the timezone, so a UTC log search can find the right window quickly.
• Anything you already tried — a re-run of a grant script, a reconnect, a retry — so we do not ask you to repeat it.

You never need to include credentials, tokens, or IAM policy JSON in a report — if we need something like that to debug an issue, we will ask for it through a secure, one-time channel, never by email or chat.

Before you write in

Two pages answer the most common questions without waiting for a reply:

• Verify access — what each grant status pill means and how to confirm access yourself, in your own audit log.
• Plans and billing — trial behaviour, upgrades, downgrades, and the 30-day grace period after a lapsed subscription.