Troubleshooting
Troubleshooting
What error codes mean, why a page didn't arrive, and how to get help fast.
What the error codes mean
When WarnFire turns an event away, the number it answers with tells you exactly which kind of problem you have:
| Code | In plain terms | Where to look |
|---|---|---|
400 | The message was malformed — a missing required field, a bad timestamp, or a value over its limit. | Compare your request with Open an incident . |
401 | The integration key wasn’t recognized — wrong, expired, or revoked. | Check or rotate the service key . |
403 | Your workspace is suspended, usually over billing. | The owner should follow billing recovery . |
404 | The web address is wrong — often a mistyped adapter name. | Check the URL against the adapter’s docs page. |
409 | A delivery ID was reused to mean something different. | The safety catch explains the rule. |
413 | The message was too large. | Trim the payload; link to big data instead of embedding it. |
429 | Too many new problems too fast, or too many incidents open at once. | Review the two limits . |
Every HTTP response carries a full UUID in the X-Request-ID header. With
curl, add --include to print it. In the web console, copy the reference from
the error banner. Keep the complete value; it lets support find the exact
request without receiving credentials or payload data.
“The incident opened, but nobody was paged”
Walk this list top to bottom — it’s ordered by how often each one is the answer:
- Is there a maintenance window active? The incident will say “Paging paused for maintenance.” That’s deliberate quiet time, not a fault.
- Is everything switched on? The responder, schedule, escalation policy, and service each have an enabled/disabled state. Follow Clear readiness issues and use each Fix → link.
- Is anyone actually on call right now? A schedule can have gaps. Its card shows On call now — if it says Uncovered, adjust the rotation times or add an override.
- Was it a repeat? If the same problem was already open, your event became an update on the existing incident — check its Updates tab. The update does not start a second escalation merely because it arrived. The existing policy can still continue through its configured steps and channels.
- Can the phone be reached? In the app’s Settings tab, the footer should say Notifications: On. If it says Permission needed, enable notifications for WarnFire in the phone’s settings.
Open Delivery Activity to confirm whether WarnFire created an attempt, handed it to a provider, received terminal evidence, or recorded a failure.
“The notification opened the wrong screen”
An incident-assistance invitation should open its one-page invitation brief, whether WarnFire was in the foreground, in the background, or fully closed. A normal page opens the incident itself.
Update to the newest app version and try the same notification again. If an invitation still opens the general incident screen—or opens nothing after a cold launch—tell support:
- whether the app was foregrounded, backgrounded, or fully closed;
- roughly when you tapped the notification;
- your app version; and
- the complete request reference shown in the app, if one appears.
Never send your password or a push token.
Getting help
Write to WarnFire support
with what you
expected, what happened, and the complete X-Request-ID or error reference.
One rule protects you: never send a password, access token, integration key, or console token to anyone — support will never ask for one.