Alerts, uptime checks and incidents in one place
Rules on the same events you already send, delivered with retries and escalation, and an incident to attach the evidence to.
Alert rules
A rule watches one project. Free workspaces cannot create alert rules; Pro and Enterprise can create as many as they need.
| Rule | Fires on |
|---|---|
ERROR_RATE_SPIKE | The error rate rises past your threshold. |
LATENCY_SPIKE | Request latency rises past your threshold. |
NO_TRAFFIC | A project stops receiving requests. |
REVENUE_MILESTONE | Revenue reaches a milestone you set. |
REVENUE_DROP | No revenue events arrive during business hours. |
DEPLOYMENT_ANOMALY | The error rate spikes shortly after a recorded deployment. |
UPTIME_CHECK_FAILED | The uptime probe fails on its checks of the project URL. |
RUNNER_UNAVAILABLE | A recovery runner has not checked in (see below). |
Before you turn a rule on, optic backtest <project> tests a condition against historical data, with --type, --threshold and --days.
Delivery
A rule can notify by email, Slack, webhook, Zapier, PagerDuty, SMS or web push. Notifications are not fire-and-forget. Each one is a stored delivery that is claimed atomically, retried with bounded exponential backoff, and moved to a failed state if the retries run out, so a restart or a provider outage does not silently lose a page. The delivery history shows which attempts happened.
Escalation
An escalation policy is an ordered list of steps with a delay in minutes between them. Steps are stored with a future time rather than held in memory, so a pending step survives a restart, and resolving the incident first cancels the steps that have not come due.
Uptime, status pages and maintenance
- Uptime checks
- Each project's URL is probed on a 60 second background loop. Only a total failure of every fresh probe pages anyone; a partial failure stays visible in the dashboard.
- Status pages
- Public pages with status updates, on Pro and Enterprise.
- Maintenance windows
- Planned windows, once or recurring daily or weekly. They silence alerting and announce themselves on the status page.
- Incidents
- Open one from the dashboard or with
optic incidents open --title "...". Notes and evidence attach to it.
Optional: bounded Kubernetes restarts
optic recover restart previews and, only when you add --execute, performs a rolling restart of one named Kubernetes Deployment, recorded on an open incident. The preview is read-only and shows the exact target. Execution refuses paused, deleting or scaled-to-zero Deployments, and verifies that the rollout completed. Credentials stay on the machine that runs the CLI.
It does not repair bad configuration, exhausted capacity or a broken release, and a finished rollout does not prove the application is healthy. Rollback, scaling and database repair still need a person.
Want to see alerts on one of your products? Early access starts with a conversation.
Talk to the founder on WhatsApp