Troubleshoot from the symptom

Start from what you can see. Each section ends with how to confirm the fix took.

A monitor stays pending or unknown

1. Open Dashboard → Monitors and confirm the monitor is active.
2. Open the target from a network outside your own infrastructure. A private hostname cannot be reached by a public check.
3. For HTTP, confirm the configured method and accepted status range. For TCP, confirm the port. For DNS, confirm the record type and expected value.
4. Wait for the next configured check rather than repeatedly saving the same settings.

The fix has taken when the monitor row shows a recent check time and an up or down state. If it stays unknown, note the monitor type, target, last-check time and any visible error before you contact support.

A healthy service is reported down

Compare InBrief's request with the request your service actually expects. Redirects, required headers, IP allowlists and an endpoint that succeeds only with a session are common differences.

curl -i --max-time 15 https://service.example.com/health

To confirm, run the same unauthenticated request from outside your network, then wait for two consecutive InBrief checks. Do not close an incident because one manual request passed.

A custom domain is waiting for its certificate

1. Confirm the hostname is a subdomain such as status.example.com, not the bare domain.
2. Confirm the CNAME value exactly matches the value shown in Dashboard → Status page → Domain.
3. Turn off any proxy/CDN mode on that DNS record while the hostname is being validated.

dig CNAME status.example.com +short

The fix has taken when the command returns the target InBrief shows and the dashboard changes from waiting to active. DNS caches can delay the second step after the first is already correct.

Subscribers were not notified

Confirm the incident update was published with notifications enabled, the subscriber completed double opt-in, and the configured sending provider still verifies successfully. A silent correction intentionally updates the page without sending a message.

Check the delivery status in the dashboard rather than the presence of the public incident: publishing and email delivery are separate outcomes.

An API request returns 401, 403, 413 or 429

Continue in the Developer quickstart, which shows both credential families and an error response.

Three answers that look like faults and are not

Each of these is deliberate, and each of them looks like a bug from the outside. They are here so you can stop looking.

A sign-in link never arrives, and the page still says it was sent

Sign-in requests are rate limited per address. Past the limit the page answers exactly as it does on success and no mail is sent, because an answer that distinguished the two would tell anybody who can type an address whether it has an account here. Wait a few minutes and ask again; if the link still does not arrive after that, it is a mail problem rather than this.

Subscribing answers the same whether or not the address was already subscribed

The subscribe box on a public page gives one answer to every submission, including an address that is already confirmed and an address at the page's subscriber limit. Same reason: a form that answered differently would let a visitor enumerate who follows your page. The confirmation mail is the honest signal - an address that was already confirmed simply does not receive a second one.

A badge or widget URL returns an image even when the address is wrong

Badge and widget endpoints never answer 404. A slug that does not exist, a page that is paused and a page that never had the feature all return a drawn image reading unknown, because these URLs sit in other people's READMEs and documentation, and a broken image there is worse than an honest grey one. Check the slug against the page switcher at the top of the dashboard sidebar if a badge shows unknown longer than a minute.

What to collect before asking for help

• The page slug and affected screen, but never an API key or subscriber address.
• The exact time including timezone.
• The last visible state and the action that should have changed it.
• The response status and request id, if the problem is an API call.
• What you did to verify the result.