Skip to content
AskVault Docs
Try Free →

AskVault incident-response policy

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

Severity classification

We classify incidents into four severity levels:

  • P0 (full outage). Core service unavailable for all customers. Bot cannot respond on any channel. Customer chat doesn't work.
  • P1 (partial outage). A significant subset of customers or channels affected. Bot works on some channels but not others.
  • P2 (degradation). Service works but latency, quality, or feature availability degraded.
  • P3 (minor). Edge-case bugs, dashboard quirks, non-critical features impaired.

Classification happens within 15 minutes of incident detection. Severity drives the response cadence and customer-communication path.

Detection sources

Five paths to incident detection:

  1. Automated monitoring. Error tracking and the /api/health endpoint surface failures to the engineering team.
  2. Customer reports. Reports via support@askvault.co.
  3. Internal alerts. Engineering team observes anomalies during normal work.
  4. Security disclosures. Researchers reporting vulnerabilities via security@askvault.co.
  5. Sub-processor notifications. Our SOC 2 certified providers notifying us of incidents on their end.

Each path routes into the same response runbook. Detection is followed by triage within 5 minutes.

Response timeline

For P0/P1 incidents:

  • 0 minutes. Detection. Alerting notifies the on-call engineer.
  • 5 minutes. On-call engineer acknowledges and begins triage.
  • 15 minutes. Initial severity classification. First customer-facing update emailed to affected workspace owners.
  • 15 to 60 minutes. Mitigation rolling out. Follow-up update at major milestones.
  • At resolution. Affected workspace owners notified that service is healthy.
  • Within 24 hours. Preliminary incident summary emailed to affected workspace owners.
  • Within 14 days. Full postmortem shared with affected Enterprise customers.

For P2 and P3 incidents, the timeline relaxes. P2 typically resolves within 4 hours; P3 within 1 business day. Postmortems for P2/P3 are internal-only unless customer impact warrants disclosure.

Containment actions

When an incident is detected, the on-call engineer chooses from a runbook of containment actions:

  • Kill switch on a specific feature. Disable the offending feature workspace-wide without taking down the whole platform.
  • Roll back a deploy. Revert to the previous known-good version. Typically 90 seconds via our deploy pipeline.
  • Restart, redeploy, or restore. For compute failures, restart or redeploy the affected Fly machine from the last known-good release on main. For database issues, restore via Neon's point-in-time recovery. AskVault currently runs in a single region (Fly.io Mumbai) — there is no standby region to fail over to.
  • Rate-limit traffic. For DDoS or runaway-customer scenarios, tighten rate limits on the affected dimension.
  • Isolate the affected workspace. Rare. For incidents where a specific customer's workspace is corrupted or compromised.

Containment runs in parallel with investigation. We don't wait for root cause before mitigating.

Customer notification

Two channels carry incident communication:

  • Email to workspace owners and designated security contacts. Fired at incident start, major milestones, and resolution.
  • In-product banner in the dashboard for affected workspaces.

For urgent questions during an active incident, contact support@askvault.co.

For security incidents involving customer data, additional direct notification via the customer's primary point of contact happens within 24 hours of confirmation.

Breach notification

A confirmed data breach (unauthorized access to customer data) triggers:

  • Within 24 hours of confirmation. Direct notification to affected customers' security contacts.
  • Within 7 days. Joint root-cause analysis between AskVault and affected customers.
  • Within 14 days. Postmortem report.
  • Coordination on regulatory notification. Under GDPR's 72-hour rule, AskVault provides the technical details and timeline; the customer (as Data Controller) handles the actual regulator notification to authorities.

Specific notification channels for security incidents are documented in your Data Processing Agreement (DPA).

Customer's role during incidents

Two things customers can do during active incidents:

  1. Watch for the email and in-product banner. Workspace owners receive email updates at incident start, major milestones, and resolution, and see an in-product banner in the dashboard while the incident is active.
  2. Document customer impact. If the incident affects your operations, document what your customers experienced. Useful for your own internal postmortem.

For active P0/P1 incidents, check your email and the in-product banner before contacting support@askvault.co — they carry the most current information.

Postmortem structure

Postmortems for P0/P1 follow a consistent template:

  • What happened. Timeline from detection to resolution.
  • Customer impact. Who was affected, what they experienced, how long.
  • Root cause. What broke, technically.
  • What we did. Investigation and remediation steps.
  • What we'll do. Action items to prevent recurrence.
  • Action items follow-up. Tracked internally; status reported in the next postmortem shared with affected customers.

Postmortems are blameless. The goal is system improvement, not assigning fault.

Incident response coverage

AskVault provides best-effort incident response for P0/P1 incidents. There is no guaranteed round-the-clock staffed rotation with fixed response-time commitments today.

  • Primary responder. The engineer who owns the affected system investigates first.
  • Escalation. Unresolved P0/P1 incidents escalate to engineering leadership.

Customers don't interact with on-call directly; communication routes through email and the in-product banner, or support@askvault.co.

Limits

  • Plan availability. Incident response applies to all paid plans. Free tier gets email notification for incidents affecting shared infrastructure, but not direct account-level outreach.
  • Postmortem distribution. Postmortems are shared by email with affected Enterprise customers under NDA; a summary is available to other affected customers on request.

Common questions

How do I report an incident?

Two paths: support@askvault.co, or security@askvault.co for security-specific reports.

Does AskVault have a bug bounty?

No formal bug bounty program today. Report suspected vulnerabilities to security@askvault.co and we'll investigate.

What about sub-processor incidents?

Sub-processors are bound by their own SLAs and incident-response. When their incidents affect AskVault customers, we notify affected workspace owners by email with attribution.

Do you publish historical incident data?

Not via a public status page today. Contact support@askvault.co for details on a specific past incident.

Can I get a copy of incident response runbook?

Internal runbook details are confidential. The published policy (this page) summarizes the customer-facing parts. Enterprise customers can request additional detail under NDA.

Was this page helpful?