Find the likely cause and check that the fix took
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
- Open Dashboard → Monitors and confirm the monitor is active.
- Open the target from a network outside your own infrastructure. A private hostname cannot be reached by a public probe.
- For HTTP, confirm the configured method and accepted status range. For TCP, confirm the port. For DNS, confirm the record type and expected value.
- 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/healthTo 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
- Confirm the hostname is a subdomain such as
status.example.com, not the bare domain. - Confirm the CNAME value exactly matches the value shown in Dashboard → Branding → Custom domain.
- Turn off any proxy/CDN mode on that DNS record while the hostname is being validated.
dig CNAME status.example.com +shortThe 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
| Status | Check first | Then |
|---|---|---|
401 | The full key and Bearer prefix | Rotate a revoked or lost key. |
403 | The key scope and enabled capability | Use an incident key for incidents and an ingest key for events. |
413 | Event API batch size | Split the batch to at most 1,000 events. |
429 | Incident API request frequency | Back off before retrying. |
Continue in the Developer quickstart, which shows both credential families and an error response.
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.