Outage App User Guide

Outage App is where your team records outages and planned maintenance, tells the right people about them, and plans and approves changes. Everything belongs to an organization (your company). People in one organization never see another's data.

Create your account and organization

1. Choose Sign up. Enter your name, work email, a password (10 to 128 characters) and your company name.
2. Open the confirmation email we send you and select the link. Your organization is created when you confirm, and you are signed in. Check your spam folder if it does not arrive within a few minutes. You can ask for another link from the sign-in page, one per minute.
3. You become the organization's Owner. Next, add your sites, services and the people to notify under Recipients, then invite your colleagues.

Signing in, and forgotten passwords

• Sign in with your email and password. Your session ends when you sign out or when an administrator ends it.
• Forgot password? on the sign-in page emails you a reset link. The reply is the same whether or not the address has an account, so nobody can use it to find out who is registered.
• You can see where you are signed in, and sign out other devices, under Settings → Security.

Joining an existing organization

Administrators invite people from Settings → Invitations. Open the link in your invitation email, set a password if you are new, and you join with the role you were invited with. The invitation only works for the email address it was sent to. If you belong to several organizations, switch between them from the menu in the top bar.

Each person has one role in each organization. The menu only shows the pages your role can use. If you open a page you cannot use, it says so.

You can never give someone a role higher than your own, and only an Owner can grant or change the Owner role. Roles are fixed; custom roles are not available.

An incident is the record of something that is affecting people: either an outage that just happened, or maintenance you have planned. It holds the times, who is affected, the running timeline and who gets updates.

Declare an incident or schedule maintenance

1. Open Incidents → New. Choose Unplanned outage (something broke) or Planned maintenance (work you scheduled).
2. Give it a Title and an optional Summary, pick a severity, and choose the affected sites and services.
3. Set the times. For an outage: Detected at (when someone noticed) and, if it began earlier, Impact began. For maintenance: Planned start. Add your best estimate of when service will be restored, or how long the work should take. You can revise it with every update.
4. Choose who should hear about it (recipient groups and individual contacts). Leave Send the first notice now ticked to email them straight away, or untick it to save the incident quietly and notify later.

Severity and status

An incident moves through Investigating → Identified → Monitoring → Resolved → Closed. Choose the next status on the incident page. Your administrator can require a note when you resolve or close (Settings → Policies). A closed incident is read-only.

Keep the timeline and the audience up to date

• Update Incident on the incident page posts a note to the timeline. Pick a new status in the same step if it has changed.
• Restoration ETA revises when you expect service back. Scope adds or removes affected sites and services. Edit details and Edit times correct the record.
• The Notify switch emails the incident's audience about that update. It is off unless you turn it on, and it is disabled until you add recipients. Use Who gets updates to change the audience at any time. Changing only the audience never sends anything.
• When you resolve an incident, the downtime is calculated for you from the start and end times.

Notices are the emails that tell people what is happening. You write and send them from the incident; the Notifications page is the log of everything sent and how each email fared.

Recipients, groups, sites and services

• Recipients are the people who get notices: a name and an email address. They do not need an account. Groups bundle recipients (for example “Plant 1 managers”) so you can pick one name.
• Sites (places) and services (systems) are the lists you choose from when you say what an incident or change affects. Add them on the Recipients page.
• Sites, services, groups and recipients can all be edited or deleted there. Deleting asks you to confirm. A site or service that is still used by an incident or change cannot be deleted; the message tells you what uses it. Past records keep pointing at it.

Import many recipients from a CSV file

1. On Recipients, find Import from CSV. Download the template if you want a starting point. The file needs a header row with email (required), name and groups (separate several groups with a semicolon).
2. Choose your file. Before anything is saved, you see how many people will be added or updated, how many groups will be created, and which rows will be skipped and why.
3. Choose Import to apply it. Skipped rows are left out; the rest are imported.

Importing only adds new people and updates names of existing ones (matched by email). It never deletes anyone and never removes anyone from a group. Each file can hold up to 2,000 rows.

Sending a notice

• Turn on Notify when you create or update an incident. The default wording suits an initial notice, an update and a resolved notice.
• Choose Preview email to see the exact wording, recipients and layout before anything is sent. You can replace the default wording. Placeholders such as {{incident_title}}, {{incident_number}}, {{incident_status}}, {{incident_estimated_end}}, {{sites}} and {{services}} fill in automatically.
• A notice cannot go to more people than your organization's limit (Settings → Policies, up to 500). It is refused before anything is sent, never half-sent.

Is it really sent? Live and sandbox

If some deliveries failed, the notice shows Retry failed deliveries. When we cannot tell whether an email went out (for example the connection dropped mid-send), we never resend by ourselves. You are asked to confirm, because the person may then get the same email twice.

Emails are plain, designed messages with your logo (Settings → Branding). They contain no tracking pixels or remote images.

A change is a request to alter something in production, planned in advance, reviewed, and scheduled. The Calendar shows approved maintenance and active incidents together so you can spot clashes.

Request a change

1. Open Changes → New. Give it a title and description and choose its type: Standard (pre-authorized, low risk), Normal (routine, normal review) or Emergency (urgent fix, expedited approval).
2. Rate the risk: Low, Medium, High or Critical.
3. Set the start time, end time and timezone, the affected sites and services, and a service impact summary.
4. Write the implementation plan, how you will validate it, and the rollback plan. Reviewers decide on these.
5. Choose Submit for approval. (If your organization does not require approval it reads Submit (auto-approve).)

Approving and rejecting

• Owners, Administrators and Change managers see an Approvals inbox. Open a request, read exactly what is proposed, and Approve or Reject it with a reason.
• The approval applies to the change as it was when you read it. If the requester edits the change afterwards, the old approval is no longer valid and the change must be reviewed again.
• Your administrator can stop people approving their own requests, set how many days a request waits before it expires, and require approval for every change (Settings → Policies).

Carrying the change out

A change moves through Draft → Submitted → In review → Approved → Scheduled → Implementing → Verification → Completed. It can also end as Rejected, Canceled, Failed or Rolled back. After approval, use the Mark … buttons on the change page to move it along as the work progresses. Every step is recorded in the activity log.

An automation does routine work for you: when something happens, check a condition, wait, ask for approval, send a notice or update an incident. You build it by connecting steps on a canvas in Workflows. There is no code.

Build one

1. Choose New workflow, or start from a template such as “notify immediately for a critical incident”.
2. Add a trigger, then add steps and connect them. Select a step to fill in its settings.
3. Use Checks to see problems, and Test to simulate a run with sample data. A test shows what would happen and sends nothing.
4. Publish to make it live. Each publish is a numbered version, and you can see earlier versions. Use Run history to see what each run did, step by step.

Using values in text

Subjects and messages can include values from the run by typing them in double curly braces, for example {{incident.number}} and {{incident.title}}. The step settings list what is available at that point, so you can pick instead of typing. Only fill-in values are supported, never code.

What to know

• A Send notification step follows your organization's email setting, exactly like notices from an incident.
• Anyone can look at workflows. Creating and editing them, and publishing, running, pausing or cancelling, are for Owners and Administrators.
• An automation never sets off other automations. A workflow that creates an incident will not start a second workflow, so loops cannot happen.

An integration gives a monitoring tool, or any system that can make a web request, a private address to send events to. Each event is recorded, and a published automation can react to it, for example by opening an incident.

Set one up

1. Open Integrations → New. Name it and, if you like, list the event kinds it accepts. Turn on Require HMAC signature verification if the sender can sign its requests.
2. Copy the endpoint URL and token. The token is shown only once. If you lose it, rotate the token on the integration's page. The old one stops working immediately.
3. Point your tool at the URL, sending the token in an Authorization: Bearer header.
4. Build an automation with a Webhook event trigger, and publish it. The integration page shows each event received, so you can confirm it arrived.

curl -X POST 'https://YOUR-OUTAGE-APP-ADDRESS/api/v1/hooks/<id>' \
  -H 'Authorization: Bearer <your token>' \
  -H 'Content-Type: application/json' \
  -d '{"eventId":"evt-1","kind":"resource.down","correlationKey":"switch-01","attributes":{"host":"switch-01"}}'

Give each event its own eventId; the reply tells you if an event was a duplicate. The correlationKey lets automations reuse one incident for repeated alerts about the same thing. After you create the integration, copy the exact URL and a ready-made example from it.

Settings is for Owners and Administrators. Everyone sees the same Overview page, with the current state of things and recent events.

The activity log

Activity (Owners, Administrators and Change managers) lists who did what and when: sign-ins, role changes, incidents, approvals, settings. Entries cannot be edited or deleted, and sensitive values are hidden before they are stored.