Skip to main content

Troubleshooting

Common issues and their resolutions when using The One Status.

1. My status page shows "All Systems Operational" but something is broken​

Cause: No incident has been declared and no automated monitoring check has detected the failure.

Resolution:

  • If automated monitoring is configured: check the Recent Checks table for the affected component. If checks show failure, the component status should have updated automatically. If not, verify the monitoring URL is reachable from outside your network.
  • If no automated monitoring: update the component status manually (edit the component → set status to Degraded or Major Outage) and declare an incident.

2. Subscribers aren't receiving notifications​

Cause 1 — Subscription not confirmed: Subscribers must click a confirmation link in the email they receive after subscribing. Unconfirmed subscriptions do not receive notifications.

Resolution: Ask the subscriber to check their inbox (including spam/junk) for a confirmation email from The One Status. They must click the link before notifications are delivered.

Cause 2 — Allow Subscriptions is disabled: The page setting Allow Subscriptions may be turned off.

Resolution: Settings tab → enable Allow Subscriptions.

Cause 3 — Subscriber is on Daily/Weekly Digest: Digest subscribers do not receive immediate notifications.

Resolution: If the client needs immediate alerts, they must update their preferences to Immediate via the preferences link in any past notification.

Cause 4 — Email delivery failure: AWS SES or SMS delivery may have failed.

Resolution: Contact support with the subscriber's email address and the timestamp of the event. Check if the email address is on a suppression list.

3. Component monitoring checks are failing but my service is up​

Cause 1 — URL not publicly accessible: The monitored URL is only reachable from within your network (e.g., an internal IP or VPN-protected URL).

Resolution: Use an externally accessible health check endpoint. The One Status checks originate from external infrastructure and cannot reach internal-only URLs.

Cause 2 — Expected status code mismatch: Your endpoint returns a status code not in the "Expected Status Codes" list.

Resolution: Edit the component monitoring config and add the actual response code (e.g., if your health check returns 204 No Content, add 204 to the list).

Cause 3 — Timeout too short: Your endpoint takes longer to respond than the configured timeout.

Resolution: Increase the timeout value in the component monitoring configuration. Typical health check endpoints should respond in under 1,000ms; consider optimizing if response times regularly exceed 2,000ms.

4. Custom domain shows "Not Verified" after adding DNS records​

Cause: DNS has not propagated yet, or the TXT record was added incorrectly.

Resolution:

  1. Verify the record using a DNS checker: dig TXT _statusone-verify.yourdomain.com
  2. If the record is not visible, wait 15–60 minutes for DNS propagation and check again
  3. If the record is incorrect, delete and re-add it (copy exactly from the Settings tab — do not modify the record name or value)
  4. If still failing after 24 hours, check that your DNS provider did not automatically append your root domain to the record name (resulting in _statusone-verify.yourdomain.com.yourdomain.com)

5. Webhooks are not being delivered​

Cause 1 — Endpoint not reachable: The webhook URL returned an error (non-2xx status) or timed out.

Resolution: Check the Webhook Delivery Log in the Webhooks tab. The log shows response codes. Fix the endpoint and click Test to verify.

Cause 2 — Signature verification rejecting valid requests: Your endpoint is rejecting webhooks because the signature doesn't match.

Resolution: Ensure you're using the current webhook secret. After rotating the secret, update your endpoint's verification code immediately. Verify the signature algorithm matches the documentation (HMAC-SHA256 with {timestamp}.{body}).

Cause 3 — Webhook subscribed to wrong events: The webhook is not subscribed to the event type you expect.

Resolution: Edit the webhook and ensure the relevant event types are selected (e.g., incident.created).

6. An incident appears on the public page but components still show Operational​

Cause: The incident was created without specifying Affected Components, or the affected components were not updated when the incident was declared.

Resolution:

  • Edit the incident and add the affected components
  • Or manually update each component's status to reflect the disruption

Affected components inherit their status from the incident impact level when the incident is created.

7. I can't log in to the management console​

Cause: Hub authentication is unavailable or the user account does not have a Status entitlement.

Resolution:

  • Verify you can log in to other The One Stack products via Hub
  • If Hub is down, wait for Hub to recover — the status management console is not accessible without Hub authentication
  • If you can log in to Hub but not Status, contact your administrator to verify your account has the Status product entitlement
  • Check status.theonestatus.app for any platform-level incidents affecting the management console itself

8. The public status page is not loading​

Cause 1 — Custom domain DNS misconfigured: The CNAME record is missing or points to the wrong target.

Resolution: Verify status.yourdomain.com CNAME {subdomain}.theonestatus.app in your DNS.

Cause 2 — SSL certificate not yet provisioned: DNS was recently changed and SSL hasn't propagated.

Resolution: Wait 5–30 minutes after DNS changes for SSL to provision automatically.

Cause 3 — Platform outage: The One Status itself may be experiencing an issue.

Resolution: Check The One Stack platform status or contact support.

9. Uptime bar shows gray (no data) for some days​

Cause: Automated monitoring was not configured on that component when those days occurred, or the component was created after those dates.

Resolution: Gray bars indicate no monitoring data for that day. This is normal for components added recently, for days before monitoring was enabled, or if monitoring was temporarily disabled. Once monitoring is running consistently, the bars will fill in going forward.

10. Incident history shows fewer days than expected​

Cause: The History Days page setting controls how many days of resolved incidents appear on the public page.

Resolution: In Settings, increase the History Days value. The default is 90 days. Maximum supported value varies by plan. Note: incidents older than the history window still exist in the system and are visible in the management console — they just don't appear on the public page.

When to Contact Support​

Contact support when:

  • Subscribers confirm they are not receiving notifications despite being confirmed and subscribed
  • Platform authentication is down and you cannot access the management console
  • Custom domain SSL has not provisioned after 24 hours
  • You are experiencing data loss (incidents, components, or subscriber history missing unexpectedly)

For support: file a ticket via your PSA or contact The One Family support directly.