Skip to content
AskVault Docs
Try Free →

Status page and incident communication

Written by , Principal Architect, Networks and Tech, AskVault · Reviewed by Allison Chan
Last updated: · 3 min read

Where to find the status page

status.askvault.co is reserved for this but not yet live — there's nothing to visit there today. The design below is what it will show once launched.

Once live, the page will show:

  • Overall status. Operational / partial outage / major outage.
  • Per-component status. API, widget, dashboard, channels (WhatsApp, Slack, etc.).
  • Active incidents. Description, affected components, last update.
  • Maintenance windows. Planned maintenance with start/end times.
  • Past 90 days of uptime per component.

What's monitored (planned)

Planned components, by category:

Core:

  • API (api.askvault.co).
  • Dashboard (askvault.co/dashboard).
  • Marketing site (askvault.co).
  • Authentication system.
  • Database tier.

Channels:

  • Widget delivery.
  • WhatsApp routing.
  • Telegram routing.
  • Slack routing.
  • Discord routing.
  • SMS routing.
  • Voice / telephony.
  • Email assistant.
  • Hosted page rendering.

Knowledge:

  • Indexing pipeline.
  • Knowledge retrieval.

Each component reports independently. A WhatsApp outage doesn't show widget as down.

How status is determined (planned)

Two signals, once the page is live:

  • Automated probes. External monitoring hitting critical paths on a regular interval, with multiple consecutive failures triggering an incident.
  • Internal metrics. Error rates, latency p95, queue depth tracked by our observability stack. Threshold breach triggers an incident.

Both signals would need to clear for "Operational" status.

Today, incident detection and communication run through the process in Incident response — not a public status page.

Subscribing to alerts (planned)

Planned subscription channels once the status page launches: email, SMS, and RSS/webhook for programmatic alerting (PagerDuty, Opsgenie, your own systems).

None of these exist yet. Today, get notified during an incident by asking support or your account team to add you to direct communication for your workspace.

Incident lifecycle

Each incident progresses through:

  1. Investigating. We've detected something; investigating root cause.
  2. Identified. Cause known; remediation in progress.
  3. Monitoring. Fix deployed; observing to confirm resolution.
  4. Resolved. Service back to normal; postmortem in progress.

Updates posted at each transition plus every 30 to 60 minutes during the incident.

Postmortems

After every customer-impacting incident:

  • Postmortem published within 14 days.
  • Root cause analysis (technical detail).
  • Timeline of events from detection to resolution.
  • Customer impact summary (which workspaces, what duration).
  • Action items to prevent recurrence.

See Incident response for exactly how postmortems are shared today. Once the status page is live, they'll also be published to its archive with a subscriber email.

Past-90-days uptime (planned)

For each component, the status page will show:

  • Daily uptime bar for the last 90 days.
  • Total uptime %.
  • Incidents during the period.

Green bars: 100% uptime that day. Yellow: partial outage. Red: major outage.

Until it's live, use SLA per plan and the credit-claim process there for SLA evaluation.

Maintenance windows

Planned maintenance announces at least 48 hours in advance:

  • Subject line: "Scheduled maintenance - [component] - [date]".
  • Description: what's being changed, expected impact, duration.
  • Start time in multiple timezones.

Most maintenance is zero-impact (rolling deploys, capacity changes). Occasionally maintenance requires 5 to 15 minutes of downtime; we batch these to weekends in low-traffic windows.

SLA reference

Per-plan uptime commitments:

  • Free. Best effort. No SLA.
  • Starter, Growth, Business. 99.5% target.
  • Enterprise. Custom, negotiated per contract.

See SLA per plan for full details including the credit ladder and how to claim.

Uptime for SLA purposes is calculated from our internal monitoring, reconciled against your reported downtime — not the (not-yet-live) status page. See SLA per plan for the actual claim process.

Integration with your monitoring (planned)

For teams running their own monitoring, once the status page launches:

Webhook subscription. AskVault would post to your webhook on every incident transition, with a payload shaped roughly like:

{
  "event": "incident.created",
  "incident_id": "inc_xxx",
  "component": "whatsapp_routing",
  "severity": "major",
  "started_at": "2026-05-15T10:00:00Z",
  "title": "WhatsApp message delivery delayed"
}

RSS aggregation and a JSON status API for embedding live status in your own dashboard are also planned.

None of these exist today — there's no webhook, RSS feed, or status API to integrate against yet. For programmatic incident data in the meantime, contact support.

What counts as an incident

Three severity levels:

  • Minor. Latency above normal but service functional. Few customers notice.
  • Major. A component is degraded or down. Most customers using that component affected.
  • Critical. Multiple components down or full outage. Most customers affected.

We publish all three. Some platforms hide minor incidents; we don't.

Sample incident timeline

A real-ish flow, illustrating how a public status page would communicate an incident once it's live (today, this happens through direct customer notification instead — see Incident response):

10:00 UTC. Probes detect 30% error rate on WhatsApp delivery. Incident "WhatsApp message delivery delayed" published as Investigating.

10:08 UTC. Root cause identified: upstream provider rate-limit. Updated to Identified.

10:15 UTC. Workaround deployed (alternative routing). Updated to Monitoring.

10:35 UTC. Error rate normal for 20 minutes. Updated to Resolved.

Day 2. Postmortem published with full timeline, root cause, and action items.

Subscribers see emails at each transition. Total customer impact: 35 minutes of delayed (not lost) messages.

Further-out features (beyond initial launch)

Documented for accuracy — these go beyond the base design described above:

  • Workspace-scoped incidents. Base design is global incidents; per-workspace incidents (e.g., "your specific WhatsApp number provider is having issues") would come later.
  • Custom-component status. Base design is a fixed set of monitored components; custom monitored endpoints for Enterprise contracts would come later.
  • Status page embed. Base design links out; an embeddable widget showing your relevant components would come later.

Limits

  • Postmortem publication. Within 14 days of resolution.
  • Historical retention (planned). 90 days of incident history, once the status page is live.
  • Probe frequency and status update latency (planned). Not yet finalized.

Common pitfalls

Assuming the status page is live today. It isn't — see above. Don't rely on it (or a subscription to it) for incident awareness yet; contact support instead.

Confusing planned maintenance with outage. Maintenance windows are pre-announced and typically zero-impact. Check the maintenance section, not just incidents.

Once the status page launches, expect the usual pitfalls of any status page: missing a component-specific subscription, and trusting a lagging "Operational" badge over your own monitoring during an in-progress investigation.

FAQ

Where is the status page hosted?

It isn't live yet, so there's nothing hosted today. Once launched, it will run on infrastructure separate from the main AskVault API, so it stays up if AskVault itself is fully down.

How accurate will the uptime number be?

Not yet determined — probe frequency and detection granularity haven't been finalized.

Can I get SLA credits via the status page?

No. Credits process via support tickets. The status page is informational; SLA enforcement happens separately. See SLA per plan.

Will the bot warn me about ongoing incidents during a chat?

Today, no auto-warning. Planned for integration with the status API.

Can I see status data going back beyond 90 days?

The status page isn't live yet, so there's no historical data to look up there. Once it launches, the plan is 90 days of incident history with full timelines, matching Incident response — older data available on request.

Was this page helpful?