Rules

Available on the Pro and Pro Plus plans.

Rules decide when an alert goes out, once a channel knows where to send it. They live in Project → Alerts → Rules, under the “As it stands” box that summarises what they produce together. All apply to all channels at once: email, Discord, Slack and outbound webhook. None touches monitoring itself: the checks run, the history and the incidents are written, it's the sending that obeys.

What PostShip does

Confirmation before alert

By default, an alert goes out at the first failure. You can require 2 or 3 failures in a row before alerting, to absorb a one-off network false positive, at the cost of slower detection (2 runs at 5 minutes is 10 more minutes).

The rule counts the streak: fail and error extend it, pass resets it. The alert goes out when the streak crosses the chosen number, not on each following run: a page down all night only writes to you once. It writes again only if the outage changes nature (a 503 turned 404, a missing file turned timeout). The recovery is only announced if the failure alert had gone out: with a confirmation at 3 and a 2-run outage, you receive neither.

It's also this number that decides the opening of an incident: the incident opens at the N-th confirmation, at the precise moment PostShip agrees to write to you.

Quiet hours

A daily time range, from “From” to “To” (whole hours, 0 to 23), in the time zone of your choice. A range crossing midnight (10 pm → 7 am) is understood. Leaving one of the two fields on “Disabled” disables the range. During those hours:

• an outage of the payment — a payment page of the pack or a journey failing — still wakes you;
• everything else (other failures, recoveries, content changes, DNS drifts) is held back; the checks continue and the incidents open normally;
• on the first run after the end of the range, a night report goes out on your channels and by email: the incidents opened during the range, those that closed by themselves, those still lasting. Nothing goes out if the night was quiet.

Fine-tune: 4 more rules

Under quiet hours, the “Fine-tune” card carries 4 rules, each on its own switch. A gesture saves; no button. All delay or sort, none blocks: a payment page always comes first.

• Minimum outage before alerting: only alert once the outage has lasted 5 min to 12 h, on top of consecutive failures. PostShip records the moment the streak started; the alert goes out on the run where both conditions are first met, never on the following ones. A page that stumbles 2 runs and recovers is not an outage.
• Working hours: weekdays and a slot (“09:00” → “18:00”, in the quiet hours time zone; a slot that crosses midnight belongs to the day it starts). Outside, the quiet hours rule applies: a broken payment page alerts right away, the rest is held — the incident opens, the daily digest says so.
• Severity by page type: what payment pages get and what the other pages get — “Every channel, right away”, “Email only” (channels and the webhook never hear about it), or “The daily digest” (nothing immediate). A recovery, a content change or a DNS drift follow the other pages' rule.
• Grouping: wait 2 to 30 min to gather failures that land a few runs apart into a single alert. Items wait on the project; the run that sees the window elapsed — or the tick, a few minutes later — sends them together. A page that fell and recovered within the window yields nothing. Preview deployments are never grouped.

Mute alerts now

3 buttons, “1 h”, “4 h”, “24 h”, on the Incidents page (“Mute” bar) as in Alerts → Maintenance, and “Resume alerts” to cancel. It's the on-call gesture: the siren rang, we know, we don't want to hear it 6 times. For a cut planned in advance, prefer a maintenance window, which has an end, a reason and shows on the status page.

Silencing a URL

In a URL's menu (URLs page), “Mute alerts for 4 h” removes that URL alone from the alerts for 4 hours; the rest of the project keeps alerting. “Resume alerts” cancels. The “Muted URLs” section of Alerts → Maintenance lists them with their expiry and a “Resume” button.

Set it up

Project → Alerts → Rules, “When you are told” group:

• Confirmation before alert: “1 failure”, “2 failures in a row”, “3 failures in a row”. Save.
• Quiet hours: From, To, Time zone. Save. The default time zone is your account's.
• Fine-tune: 4 switches — minimum outage (menu from 5 min to 12 h), working hours (days, From, To), severity (payment pages, other pages), grouping (menu from 2 to 30 min). Every gesture saves.

What blocks and what delays is summarised at the top of the page: “It takes 2 consecutive failures on the same URL before an alert goes out.” or “Between 10 pm and 7 am (Europe/Paris), only payment wakes you; the rest is reported in the morning.”

What triggers an alert

In order, for each run:

1. The failure streak crosses the confirmation number, and the outage has lasted the minimum delay if there is one: a failure alert is due.
2. The project's alerts are muted, a maintenance is in progress: nothing goes out, on any channel.
3. The hour is quiet, or outside working hours: only failing payment pages remain.
4. The URL is silenced: it's removed from the message; if it was the only one, nothing goes out.
5. Grouping is set: items wait for the window to end.
6. Severity by page type decides the channels for each item.
7. The same alert (same URL, same fingerprint) went out less than 10 minutes ago: nothing goes out.
8. Otherwise, sending on each connected channel, see Email, Discord, Slack.

Limits and plans

See the plans.

Troubleshooting

Why did the alert go out despite a confirmation at 3?

Look at the URL's page: the streak did reach 3 consecutive failures, perhaps over 3 5-minute runs you didn't see. An error (timeout, DNS not found) counts as a failure.

Why didn't I get an alert for a night outage?

Because the outage didn't touch payment: it was held back, and the end-of-range report listed it (“Still ongoing” or “Recovered”). The incident is in Project → Incidents, and on the status page if it was published.

Why didn't “Mute alerts for 4 h” on a URL silence the project?

It's the silencing of a single URL. For the whole project, use “Mute 1 h / 4 h / 24 h” on the Incidents page or in Alerts → Maintenance.

Maintenance

Available on the Pro and Pro Plus plans.

A one-off window or a weekly rule during which nothing alerts, announced on the status page.

A maintenance window is a cut of the alerts decided in advance, with an end you can't forget to restore and a reason that explains the hole in the history a week later. That's the difference with “Mute 4 h”, which you press after the siren rang. During the window, the checks continue: the history stays true about what the site did, only the sendings are held back.

What PostShip does

2 forms, which add up:

• The one-off window: a start, an end, an optional reason (80 characters). It ends by itself; there is nothing to re-enable.
• Recurring maintenance: one or more slots, each with days of the week, a start time, an end time and an optional reason, in a shared time zone. “Every Sunday from 03:00 to 04:30 (Europe/Paris)”, set once. If the end precedes the start, the window runs until the next day: “Saturday from 23:00 to 01:00” does cover Sunday at 0:30.

During either:

• No alert goes out, on any channel, for any URL of the project. It's the same all-or-nothing as the quiet hours of Rules.
• The public badge shows “maintenance” rather than “up”.
• The status page switches to a degraded state with the reason, and the deploy card mentions it.
• The probable cause of an incident opened during the window keeps “Announced maintenance” with the strongest score: it's the only cause you can almost assert, someone announced it.

And before:

• The status page announces an upcoming one-off window within 24 hours, with the time and the reason. Beyond 24 h, the information is of no use to someone who just found the site slow.
• The public calendar lists everything planned over 30 days (12 occurrences at most), one-off included, and also serves it as .ics at the address /s/your-slug/maintenance.ics for Google Calendar, Outlook or Apple. See Maintenance calendar.

Set it up

Project → Alerts → Maintenance gathers everything that silences alerts: “Mute now”, muted URLs, the calendar of windows and the weekly rule. Mute now and muted URLs are on every plan; the rest of the page needs Pro.

One-off window

“Plan a window” card: the day on the calendar (2 months), the start time, the duration (7 days at most, no overlap), an optional reason, for instance “Postgres migration”. The sentence at the bottom reads the window back before you set it. Upcoming and ongoing windows are listed under “Planned”, with “Cancel”; past ones under “Past”, with the number of failing checks during — silenced at the time, kept in the history. The current or next window is the one the status page announces and the .ics calendar carries.

Recurring maintenance

“Recurring maintenance” card: one slot per sentence, “Every M T W from 03:00 to 04:00”, with an optional reason. “Add a slot” sets another one (Thursday and Friday from 18:00 to 19:00, for instance), ten at most; “Remove” takes it away. One time zone for every slot, one “Save”. An end before the start means “until the next day”. The bottom line gives the next maintenance, and the card header shows “In progress · …” during a slot.

What triggers an alert

Nothing during the window. An outage that starts during the maintenance and lasts afterwards isn't replayed at the end: PostShip only alerts at the transition, and the incident stays visible in Project → Incidents. An outage that starts after the end alerts normally.

The “As it stands” box in Rules tells you when that's the case: “A maintenance window runs until 14/09 04:30: nothing will go out until then.” or “Recurring maintenance in progress — every Sunday from 03:00 to 04:00 (Europe/Paris): nothing goes out until the end.” A window scheduled for next week doesn't appear there: it doesn't explain today's silence.

Limits and plans

The status page and its calendar exist on all plans; they only announce a maintenance if a window could be set. See the plans.

Troubleshooting

Why did an alert go out during my maintenance?

Check the recurring rule's time zone: a “03:00–04:00” window in UTC isn't 3 am in Paris. The one-off window, for its part, is entered in your local time. The “As it stands” box says whether a window is in progress when you read it.

Why doesn't the status page announce my window for next week?

The announcement at the top of the page only covers the next 24 hours. The window is indeed in the calendar of the next 30 days and in the .ics feed.

Why does the badge say “maintenance” when nothing is in progress?

A recurring rule is in progress at that time. Look at the “Recurring maintenance” card: its header shows “In progress · …” when that's the case.

Taking charge

“I'm on it”: telling the team that someone is already on the incident, and handing it back.

When the channel lights up, the first question of a team of 2 or more isn't “what is breaking” but “is someone already on it”. Taking charge answers it: an “I'm on it” button, a name, a time, and a message on the channels so the others let go. It isn't an on-call, and it stops no alert: PostShip doesn't send another one for the same outage anyway.

What PostShip does

• The “I'm on it” button only appears on an incident that is open and untaken: you don't take charge of a closed outage, nor twice.
• The first to click wins: 2 people who take charge at the same second don't overwrite each other; the second reads “This incident is already taken care of, or closed.”
• The incident then shows “Taken by marie 12 min ago”: the part of the email address before the @, what you say out loud. The whole address adds nothing on an incident room line.
• The project's channels (Discord, Slack) receive a text message: “marie takes charge of the incident”, followed by the incident summary. The on-screen feedback confirms it: “Taken — announced on discord, slack.” or simply “Taken.” if no channel is connected.
• The escalation, if set, never fires for an incident someone took charge of: that's exactly what it's waiting for.
• The probable cause and the post-mortem note the taking on the timeline: “Taken by marie at 14:07 (UTC), 4 min after the start.” Or, otherwise: “Nobody took charge of this incident.”

Handing back

“Hand back” removes the taking: the incident becomes “to take” again and the “I'm on it” button reappears for everyone. No message is sent to the channels. If the escalation is set and the delay is exceeded when it's handed back, the incident will be escalated on the next run, unless it already was (once per incident).

Where

Project → Incidents, on each incident room, above the public sentence. The order is deliberate: you only write a message for customers once you know who's looking. The button doesn't exist in the chat channels nor through the API: taking charge assumes having opened the incident.

Who can take charge

The project owner and the editor members. For a read-only member, the write is refused: they read “This incident is already taken care of, or closed.” and nothing is recorded.

What triggers a message

An unreachable channel doesn't make the taking false: the write is done first, the announcement afterwards, best effort.

Limits and plans

Taking charge exists on all plans. It makes sense with collaborators (Pro Plus) and connected channels (Pro). See the plans.

Troubleshooting

Why doesn't the “I'm on it” button appear?

The incident is already taken (the name is shown) or already resolved. A closed incident can no longer be taken; its post-mortem will say who took it, or that nobody did.

Why didn't the message reach Slack?

The on-screen feedback lists the channels that accepted the message. If Slack isn't among them, the webhook answered an error: reconnect it from Integrations. The taking itself is recorded.

Why isn't the displayed name mine?

It's the part before the @ of the email address of the account that clicked. If 2 members share the same prefix (marie@a.example.com, marie@b.example.com), the name will be the same: the rest is said in the channel.

Escalation

Available on the Pro and Pro Plus plans.

An incident nobody took charge of after N minutes is sent again to the whole team, once.

The first alert goes to the owner and to the channels. If nobody clicks “I'm on it” because the owner is in a meeting, on holiday, or the alert got lost in a chatty channel, the incident sleeps. Escalation is the second ring, to every member this time, by email: the channel that always ends up being read. No on-call, no rotation: it's the smallest mechanism that keeps an outage from staying orphaned.

What PostShip does

Every 2 minutes, for each project where a delay is set, PostShip looks for the incidents that meet 4 conditions:

• open (no recovery),
• without someone in charge,
• never escalated,
• started more than N minutes ago.

For each one, it marks the escalation then sends the same message on 2 paths at once:

• By email, to all recipients: the project owner and the members who accepted their invitation, deduplicated. Subject: Incident unattended for 30 min — My site. Body: the incident summary, “Nobody clicked “I'm on it”. Anyone?”, and a “Take it” button to the Incidents page.
• On the connected channels (Discord, Slack): the same text.

Once per incident. Escalation doesn't repeat, doesn't go up a level, and doesn't exist for an incident already taken or already closed. 2 overlapping runs cannot escalate twice: the mark is set before the sending.

Set it up

Project → Alerts → Rules, “If nobody answers” group: a menu.

Save. The delay runs from the start of the incident, not from the alert: with a confirmation at 3 failures, the incident starts at the third confirmation.

What triggers escalation, and what doesn't

• Escalation ignores the alert sending rules: quiet hours, “Mute”, maintenance don't hold it back. An incident opened during a maintenance and not taken will be escalated after the delay. If you don't want an escalation that night, set “No escalation” for the duration of the operation.
• An incident taken before the delay is never escalated, even if it's handed back afterwards.
• An incident resolved before the delay is never escalated.
• Escalation appears on the probable cause timeline: “Escalated to the whole team at 14:37 (UTC), 30 min after the start.”

Limits and plans

See the plans and Team.

Troubleshooting

Why didn't the escalation go out?

Look at the incident: it was taken or resolved before the delay, or it already had been (once per incident). Also check that the delay is set on this project, not on another one.

Why did I receive the escalation when I had muted the alerts?

That's intended: “Mute” holds back the check alerts, not the reminder that an outage has nobody on it. Click “I'm on it” on the incident, or switch escalation to “No escalation” during the operation.

Why didn't a member receive the email?

Only members whose invitation is accepted are recipients. A pending invitation receives nothing.