Automatic posts

Let a status page post by itself when a critical monitor incident lasts. Off by default, in fixed translated wording, with the exact rules for when it posts, stays quiet and steps aside.

With automatic posts on, a page announces a confirmed critical monitor incident by itself and resolves the post when the incident is over.

It is off by default, per page. Without it, a monitor's incident only moves its component's status, and only a person posts.

Turn it on

In the dashboard, use the toggle in the page's settings. From a terminal (CLI 0.24.0 or later):

nrc monitor status-pages update acme --auto-post
nrc monitor status-pages update acme --auto-post=false

Through the API, send the setting in PATCH /status-pages/{id}:

{ "settings": { "autoPost": true } }

It is the autoPost field of a page's settings. Creating a page without it leaves it off. It takes the same permission and scope as any other change to the page: monitor:UpdateStatusPage and monitor.statuspages.

What triggers a post

A monitor incident causes a post when all of these hold:

Its severity is critical.
It is open on a component of the page, through an aspect that component counts.
It has been open for 3 minutes, on top of the monitor's own confirmation.
The page is published and has automatic posts on.
The organization isn't blocked over unpaid invoices.
No post of the page has ever linked it, and the rules below don't hold it back.

Monitor compares what is open with what the post says every 30 seconds, so a post can appear up to 30 seconds after its 3 minutes. After that, it is public within a minute, like any other post.

The wording

The text is fixed. You can't change it per page.

Part	English text	Emailed
Title	Service issue detected
First update	Our monitoring detected an issue affecting this service. We will post here when it is resolved.	Yes
Last update	Our monitoring shows the service is working normally again.	Yes
Ended by a person's post	Further updates are in a newer post.	No

The post starts with the status investigating and the impact major, naming the components in trouble as major_outage.

The page and the emails show this in the reader's language. page.json and the feed show the English.

What never appears

The post has no field for the monitor's name, target, error text or evidence. The rules see only ids and times, and the text is constants, so none of that can reach it. Readers see the fixed text and the public names of your components.

The rules

Situation	What happens
A warning, such as a slow site or a certificate some weeks from expiry	Nothing. It shows on the component, and only critical incidents post.
A critical incident open under 3 minutes	Nothing yet, so a blip doesn't go public.
It has been open for 3 minutes, and no automatic post is running	One post, emailed to subscribers.
More incidents open while a post is running	They join it at once, however young, with no update and no email. The system runs at most one post per page.
One component recovers while others are down	It shows operational. No update and no email.
Everything has recovered	After 5 quiet minutes, the post resolves with its last update, emailed.
A new incident opens during those 5 minutes	It joins the same post at once, with no update and no email. The 5 minutes start again once it is over.
An automatic post has ended, in any way	A new one waits 15 minutes. Incidents still open after that can post.
Any post of the page, open or resolved, has linked the incident	It never causes a new post. A monitor incident posts at most once per page.
A person's post links the incident first	No automatic post for it, ever.
A person's open post links an incident the automatic post holds	The incident leaves the automatic post. If that leaves nothing open on it, that post ends at once with "Further updates are in a newer post", and no email, because the person's post says what's happening.
A person posts an update on the automatic post, or edits it	It is handed over for good. The system never touches it again, and you resolve it. Its links still count, and a new incident can open a new automatic post beside it.
A person resolves the post while the monitor is still down	It stays resolved. The incidents it linked never post again.
Automatic posts are turned off while a post is open	Nothing new joins. The post still ends by these rules, rather than staying open for ever.
The organization is blocked over unpaid invoices	No new post, and nothing joins. An open post still ends.
The page is unpublished	No new post. An open post still ends, and sends no email.

Things that follow from the rules

The components stay truthful, within one limit. During both waits a component that no post covers follows its monitor as usual and shows under "Current problems". While the automatic post is open, what it says about a component wins, so a component it names as recovered shows operational even if a warning is open on it.

Some subscribers hear about it late. Joining sends no email. A subscriber who chose only a component that joined later gets no opening email, and gets the last update, because the post names their component by then. See Who gets what.

A person can always take over. Post an update on the automatic post to run it yourself. Or write your own post and link the monitor incident, for instance with Post to status page on the incident's page. The automatic post steps aside by the rules above.

In the API and the audit log

A post's autoPosted is true when the system wrote it, and stays so. autoManaged is true while the system still runs it, and turns false for good once it has ended or a person has updated or edited it.

In the public data, an automatic post's incident carries fixedTitle and its updates fixedText: codes for the wording, next to the English. See Public data.

The audit log records a post being created and ended by the system, as status_page_incident.auto_posted and status_page_incident.auto_resolved.