---
title: "Alerts, uptime checks and incidents | OpsOptic"
description: "Alert rules, seven delivery channels with retries and escalation steps, uptime checks, status pages, maintenance windows and incidents."
image: "https://opsoptic.com/og-image.png"
---

# 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.

[Talk to the founder on WhatsApp](https://wa.me/5548992091242?text=Hi!%20I%20saw%20the%20OpsOptic%20site%20and%20I%20would%20like%20to%20talk%20about%20early%20access.%20%28from%3A%20alerts%20top%29)

## 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](https://wa.me/5548992091242?text=Hi!%20I%20saw%20the%20OpsOptic%20site%20and%20I%20would%20like%20to%20talk%20about%20early%20access.%20%28from%3A%20alerts%20page%29)