Support, incidents and service evidence
Know which service signals are public, how incidents are communicated and which commitments require a contract.
Last updated 2026-08-28
What you'll achieve
- Check the correct health signal
- Submit an actionable incident report
- Evaluate contractual support boundaries
Public status evidence
The canonical status page reports a current readiness check for the dashboard and control plane. It does not currently publish historical uptime, a public incident archive, customer-application health or regional edge health. Customers should monitor their own production URLs from the geographies important to their users.
Contact and incident updates
Standard support is asynchronous by email at support@blinkhost.me. BlinkHost does not currently advertise phone, live-chat, 24/7 emergency coverage, public support hours or plan-specific initial-response targets. Include UTC time, workspace and project, affected URL, release identifier, visible error and business impact. Never email a password, token, secret value, private source or customer record.
For a confirmed platform incident, BlinkHost communicates material customer impact through the available status and account-contact channels and sends follow-up information proportionate to the incident. No fixed public update interval is currently promised. Enterprise escalation contacts, response targets, update cadence, availability targets and service credits apply only where written into the signed agreement.
Recovery evidence
Retained deployments support application-artifact rollback. Runtime-policy history supports policy rollback. Neither operation restores database rows, secret values, domain-provider state or customer-controlled source outside the retained project. Standard plans do not publish an RTO, RPO or disaster-recovery test commitment. Keep independent copies and test recovery procedures required by the workload.
Published operating boundary
Standard support has no published fixed operating hours, first-response target or 24/7 emergency promise. Email requests are accepted at any time and handled asynchronously; receipt is not a response-time commitment. Buyers that require staffed coverage windows, escalation contacts, update intervals or service credits must place those terms in a signed Enterprise agreement.
The public status page is a current control-plane readiness signal, not a historical uptime report and not a monitor for an individual customer application. BlinkHost does not currently publish an incident archive or a measured public uptime percentage. Use independent synthetic monitoring for the deployed URLs and regions material to your users.
Application rollback restores a retained verified release. It does not restore database rows, external provider state, secret values or customer-controlled source. No standard public plan currently carries a published RTO or RPO. These are explicit service boundaries, not guarantees implied by the presence of deployment history or database tooling.
Help improve this page
Sign in to send page-specific feedback. For account-specific help, email support@blinkhost.me.