Support & Operations
Share this page with customer admins so they know how to reach us and what to expect during maintenance windows.
Help Center route
Inside the product, #/help-center is the workspace facing jump table for
support materials.
The route now uses separate sections so users do not have to scan one crowded page:
- Overview: choose whether you need search, a guided workflow, or a contact path.
- Search: search common terms such as billing, web access, repo, wallet, and evidence.
- Workflows: short guided starts for common jobs.
- Playbooks: longer response runbooks and the Security/Evidence FAQ.
- Guides: grouped product and operations docs.
- Contact: support, security, and legal contact paths.
Use it when the correct downstream workspace or docs page is not obvious yet.
Contact matrix
| Need | Contact | SLA |
|---|---|---|
| Critical outage / blocking incident | [email protected] + escalation hotline | 1 hour |
| Feature/questions | Customer success manager | 1 business day |
| Security disclosure | [email protected] (PGP available) | Same day acknowledgment |
Provide your own escalation emails/phone numbers here if you host Dralvia yourself.
Maintenance & releases
- Weekly release window: Tuesdays 18:00 to 20:00 UTC with rolling restart and zero downtime for scanning APIs.
- Emergency patches: announced via email and in app banner. Look for notifications near the burger menu.
- Extension updates: Chrome updates MV3 packages automatically; post an advance note in your internal chat at least 24 hours in advance.
- Public status behavior:
status.dralvia.techis maintenance aware. During planned work it keeps a maintenance view visible through API restarts, container reboots, and short refresh failures instead of downgrading to a generic unavailable state.
Incident communications
- Status updates are posted in the admin console (
#/dashboardbanner) and via email. - Every major incident receives a postmortem with timeline, root cause, and remediation actions. EvidencePacks (Dralvia's exportable evidence reports) are attached when relevant.
Customer responsibilities
- Keep API keys secret, rotate quarterly, and disable unused keys.
- Ensure sensor and extension deployments stay up to date; monitor the workspace KPI dashboard for anomalies.
- Update your DPIA/ROPA documents with any new data flows introduced by Dralvia.
Resources
- Docs portal (this site)
- Postman collection (
docs/postman/Dralvia_Public_API.postman_collection.json) - SDKs (
sdks/python,sdks/js) - TicketBridge CSV exports for quarterly reviews
- Error Dictionary (top recurring fixes)
- Glossary (plain language terms)
Update this section with your own internal contacts if you resell or operate Dralvia for downstream customers.
Who this is for
This guide is for workspace owners, workspace admins, and security operators who need clear, repeatable steps without support intervention for day to day execution.
Role-based start here
- Workspace Owner: Start with Before you start, then complete Step by step and Known limits and rate limits.
- Workspace Admin: Focus on Step by step, What each button does, and API and automation.
- Security Analyst: Start at Day two operations and Troubleshooting, then use API error quick reference.
- Integrator/Engineer: Start at API and automation, then validate with Step by step and FAQ.
Before you start
Use this short checklist before making changes:
- Confirm you are signed into the correct workspace account.
- Confirm your role includes the permissions needed for this page.
- Confirm your browser session is fresh (if pages behave unexpectedly, sign out/in once).
- Confirm required prerequisites (API keys, agent enrollment, license, upstream integrations) are already in place.
Step-by-step
Follow this sequence for predictable results:
- Open the workspace from the account menu.
- Review current status/health/last update indicators before making changes.
- Apply one change at a time and save.
- Run the available validate/probe/refresh action.
- Confirm the expected output appears (status change, new event, successful result).
- If behavior is not as expected, use Troubleshooting below before repeating actions.
Day-2 operations
After initial setup, keep this surface healthy with a simple routine:
- Daily: verify data freshness and error banners.
- Weekly: review trends, limits, and failed actions.
- Monthly: review permissions, keys/tokens, and stale entities.
- After any incident: capture evidence and update your internal operating notes.
What each button does
Button labels can vary by module, but behavior is consistent:
- Refresh: reloads the latest data from backend APIs without changing configuration.
- Save: persists workspace scoped configuration changes.
- Run/Probe/Validate: executes a non destructive health or verification action.
- Download: fetches workspace scoped artifacts, for example bundle, checksum, signature, or report.
- Verify: checks integrity/consistency and returns pass/fail details.
- Enable/Disable: toggles module behavior for your workspace; audit evidence should be recorded.
If a button appears disabled, check role permissions, required fields, and workspace license or feature entitlement first.
Self-check playbook
Use this five step isolation flow before escalating:
- Configuration: confirm required inputs are present and formatted correctly.
- Permission: confirm your role can perform the action (
401/403usually indicates authz/authn mismatch). - License/feature: confirm the feature is enabled for your workspace plan and module toggles.
- Quota/rate limit: check for
429responses and cooldown windows. - Service health: if you see
5xx, retry once after 30 to 60 seconds and capture exact error text.
If still failing, escalate with workspace ID, UTC timestamp, route, action, payload shape with no secrets, and screenshot or error response.
Troubleshooting
Use this quick triage order to reduce time to fix:
- Auth/session: refresh token by signing out and back in.
- Workspace context: confirm you are in the correct workspace.
- Inputs/config: verify required fields and formats.
- Quota/license: confirm limits and feature entitlement.
- Service health: retry after short delay if backend is transiently degraded.
For escalation, include workspace ID, timestamp in UTC, route name, action attempted, and full error message.
API and automation
Everything in this page should remain workspace scoped. If your team prefers automation, use the corresponding API endpoints with the same guardrails as the UI:
- Use authenticated requests bound to your workspace context.
- Use idempotency and retry controls where available.
- Validate outcomes in the UI after automated runs.
If your endpoint mapping is not obvious, start from Help Center and follow the linked API docs.
Next best actions
After finishing this page, continue with related workflows so your workspace setup stays complete:
- EDR response and host actions
- Web Access Protection and dry run events
- Identity risk and OAuth response
- EvidencePack verification and transparency log
- Risk economics and plan recommendation
FAQ
Q: I clicked save but nothing changed. A: Refresh once, confirm permissions, and verify required fields.
Q: Why do I see missing API key/unauthorized errors? A: Confirm your workspace API key or session is valid and mapped to the correct workspace scope.
Q: Can non admin users use this page? A: Usually read only access is possible; write actions require workspace admin or equivalent roles.
Next steps
After finishing this guide:
- Validate the result in the related dashboard/workspace.
- Export or capture evidence if this affects compliance/incident operations.
- Share the same runbook internally so other operators follow identical steps.
- Return to Help Center for adjacent workflows.
API error quick reference
Use this matrix when a UI action fails with an HTTP/API error.
| Error | Meaning | What to do now |
|---|---|---|
401 Unauthorized | Session token is missing, expired, or request is not authenticated. | Sign out and back in, refresh once, then retry. Confirm your session is active in the correct workspace. |
403 Forbidden | You are authenticated but your role is not allowed to perform this action. | Confirm your role includes the required permission for this button or action. Ask a workspace admin to grant access. |
404 Not Found | The route or resource does not exist in current workspace context, or the feature is not enabled. | Confirm URL, route, workspace context, and feature availability. Refresh and retry; if persistent, capture timestamp and route and contact support. |
429 Too Many Requests | Rate limit or quota window was exceeded. | Wait for cooldown or reset window, retry once, then reduce burst traffic and back off if automated. |
500 Internal Server Error | Backend failed unexpectedly while processing the request. | Retry after 30 to 60 seconds. If still failing, escalate with workspace ID, UTC time, route, action, and full error text. |
Known limits and rate limits
These limits can vary by plan and feature, but behavior is consistent:
- Burst traffic can trigger
429 Too Many Requests. - Workspace quotas apply per feature/module and reset on configured windows.
- Repeated retries without backoff can extend recovery time during saturation.
Recommended operator behavior:
- Retry once after cooldown for 429 responses.
- Use exponential backoff in automation.
- Monitor usage/quota dashboards for sustained high utilization.
- Request quota review when normal workload regularly approaches limits.