Connect Notion so resolved incidents turn into ready-written postmortem pages in a Notion database, and so your automations can file and update tasks there. This is for anyone setting up InfraNest's Notion integration for their team.
#Overview
- Every incident you resolve can become a postmortem page in Notion, written from what InfraNest recorded: what failed, the timeline, linked tickets, and what changed beforehand.
- Your team only has to add what it learned and what will change — the facts are filled in for you.
- Automations can also file, comment on, and update tasks in a Notion database you use for tracking work.
NoteA Notion connection can only see the pages and databases you explicitly give it. A valid connection that hasn't been given anything can reach nothing at all — skipping that sharing step is the most common reason nothing appears in Notion.
#Connect your workspace
- Open Integrations in the sidebar, find Notion, and click Connect with Notion.
- Notion asks you to approve access and to choose which pages and databases to share — pick the database you want postmortems written in while you're there.
- You land back in InfraNest, connected.
If Connect with Notion is greyed out, your InfraNest administrator hasn't registered a Notion connection yet — use a token instead, which works the same way once set up.
#Connect with a token
- In Notion, open the developer portal at
app.notion.com/developers/connections. - Under Internal connections, choose Create a new connection, give it a name, and pick your workspace.
- Open the Configuration tab and copy the Installation access token.
- In InfraNest, open Integrations in the sidebar, then Notion, and paste it in.
InfraNest checks it straight away and shows which workspace it belongs to.
#Share the database with the connection
Do this even if the connection says it is working — a token on its own can see nothing.
- In Notion, open the database you want postmortems written in.
- Click the ••• menu at the top right.
- Choose Connections → Add connection, and pick the connection you just made.
- Confirm it can access the page and everything inside it.
If you connected with Connect with Notion and chose the database on Notion's approval screen, this is already done.
#Write a postmortem when an incident resolves
- Open Integrations in the sidebar, then Notion.
- Under your connection, find Postmortems and turn the switch on.
- Pick the Database the pages go into. If you shared only one, it is already picked.
- Choose Which incidents: all of them, only critical ones, or only the monitors you pick. Choose critical only if a page for every short blip would be noise.
- Click Save changes.
From now on, each time an incident resolves, a new page appears in that database. Its title is Postmortem: followed by the incident's title, and it has these sections:
- Summary — what failed, the impact, when it started and was resolved, how long it lasted, and who acknowledged it.
- What the team said — the summary your team saved on the incident, and what it was, if anyone said.
- Timeline — the first failure, the alert, the acknowledgement and the recovery, with every team note, status page update, and ticket opened, finished or commented on, in order and in your workspace's time zone.
- Linked tickets — the Jira or Linear tickets for the incident, with a link and their last status.
- What changed just before — deploys, changes made in InfraNest to the monitor, its server, firewall or DNS records, and DNS edits made at your provider, in the 30 minutes before it started, with the likely cause when there is one.
- Follow-up — left for your team: what will change so it does not happen again, and who owns it.
When your team has written the incident's review in InfraNest, the page is written from it: What happened, Impact and Why it happened come right after the summary, and What we change lists the review's follow-ups, each with its issue and the issue's state, in place of the empty Follow-up section.
The page is written in your workspace's language, and the link at the top opens the incident in InfraNest.
The switch is an automation that the integration manages for you. You can follow its runs in Automations, but you change it here, not in the automation builder. Turning the switch off pauses it and keeps its history.
Disconnecting the workspace turns the switch off with it, and it is not listed among the automations that get switched off. InfraNest keeps what it was set to — the database and which incidents — for 30 days. Connect the same Notion workspace again within that time and the screen you land on asks whether to turn Postmortems back on, into the same database, as before. A different workspace is not offered it.
#Publish the review to Notion
The review your team writes on the incident page is the record; Notion is a place it is published to. When the Postmortems switch is on, Notion is ticked under Also publish to on every review, and Finish review writes the page. The switch does not have to be on: tick Notion on the review, or use Publish ▾ → Notion on a finished review, and pick the database.
WarningPublishing again updates the same page — you never get two. After the review is finished, every change you save updates the page a minute later. Change the review in InfraNest, not the page in Notion: the page is rewritten from the review each time, and edits made in Notion are not read back.
The review row on the incident's Follow-up panel shows a Notion chip that opens the page, with the database's own Status when it has one, otherwise when it was last updated.
A postmortem someone wrote in Notion: choose Publish ▾ → Link a write-up made elsewhere on the review and paste the page's address. InfraNest shows its title, who edited it last and when, and its Status when the database has one. It never copies the page's text. The connection needs access to the page, as for any database.
#Check it with a test page
- Before an incident resolves, click Write a test page.
- InfraNest writes a real page into the database you picked, from your most recent resolved incident, titled Test postmortem. If no incident has resolved yet, it writes a made-up one, clearly titled Sample postmortem.
- A link to the page appears straight away.
You can delete the test page in Notion whenever you like.
#Write a postmortem from your own automation
If you want postmortems only in some cases — say, only for incidents on your payment monitors, or only on weekdays — build a rule yourself and add the step Write a postmortem: pick the Notion connection and the database. It works on any incident trigger. The recipe Critical incident resolved → write a postmortem in Notion in the automation gallery sets one up for you.
The page's link is available to later steps as {{incident_report.url}}, so you can post it in Slack straight after it is written.
#Also: file tasks from an automation
If your team keeps a task board in Notion, automations can file tasks there too. Build a rule as usual and pick Create Notion task as the action.
- Notion database — start typing and pick from the databases this connection can see. If the list is empty, the sharing step above has not been done yet. You can also paste the link to a database straight out of your browser.
- Title — plain text, and you can drop in values from whatever triggered the rule, so the task arrives with the domain name or monitor already in it.
- Body — optional. Becomes the text inside the page.
- Properties — optional, and this is the interesting part. Your database has whatever columns you gave it, so instead of a fixed list of fields, you add a row per column you want to fill: pick the column by name, then type or pick the value. The column's type is shown underneath, so you can see whether it wants a date, one of a set of options, a number, and so on.
The task the rule creates is available to later steps in the same rule, so you can post its link to Slack straight after filing it — or comment on it and move it, using the two actions below.
#Comment on a task, or move it along
- Comment on Notion page — adds a comment. Useful as the other half of a rule that files tasks: the monitor recovers, and the task says so.
- Update Notion page — sets any of the same properties, so a rule that opened work can also finish it: set Status to Done, push a date out, or tick a checkbox. It can also move the page to the trash. You do not have to say which database the page is in — it already knows.
Both ask which page. Paste its link from Notion, or refer to the task an earlier step in the same rule created — the picker of earlier values offers it.
#Whose name is used
A Notion connection writes as its own integration, not as anyone's personal account, whether you used Connect with Notion or an installation access token. The connection's row on the Notion page says so. Pages and comments InfraNest creates show the integration as their author, and nobody leaving your team affects the connection.
#Reconnect or replace the token
If Notion stops accepting the connection — its access was removed in Notion, or the token no longer works — the connection shows a red card with Reconnect (or Replace the key for a connection made with a token). Use that, not Disconnect:
- Reconnect signs you in to Notion again. Replace the key asks for a new installation access token, tries it first, and only swaps it in when it works.
- It is the same connection afterwards, so Postmortems, your automations and the pages already linked to incidents all keep working. Nothing is switched off.
- Use the same Notion workspace the connection was made for. If you sign in to, or paste a token for, another one, nothing is changed and you are told so — connect that one as a new connection instead.
You can find all of these under the ⋯ menu on the connection: Test, Reconnect or Replace the key, Rename and Disconnect.
#Disconnect
- Open the ⋯ menu on the connection and select Disconnect.
- Before anything happens, InfraNest shows what it will change:
- Postmortems stops, if it was on. Its settings are kept for 30 days, so connecting the same workspace again offers to turn it back on.
- The automations that use this connection are listed by name. They are switched off, not deleted.
- InfraNest will remove the stored sign-in for this connection.
Pages InfraNest already wrote stay in Notion. Disconnecting doesn't remove InfraNest's access on Notion's side: to do that too, remove the connection in Notion — for a token, in Notion's developer portal.
#Troubleshooting
No page appeared after an incident resolved. Check that the switch is on and that the incident matches Which incidents — a minor incident is skipped when you chose critical only. Then open the automation from the link in the Postmortems section: its run says what happened, including any refusal from Notion.
The database list in Postmortems is empty. Nothing has been shared with the connection yet. Share the database as described above, then reload the page.
"Notion cannot see that page or data source." This is the sharing step. Open the database in Notion, click ••• → Connections → Add connection, and add this connection. Notion reports "you were never given this" and "this does not exist" the same way, so the message says the likelier of the two.
A list says why it has nothing to offer. When Notion could not be asked, the list says so instead of coming up empty:
- Needs to be connected again — the connection's access was revoked or has run out. Connect it again under Integrations in the sidebar. The list fills in on your next try — there is nothing to wait for.
- Isn't allowed to read this list — the connection works, but its access does not cover this list. Give it that access in Notion, or type the value.
- Couldn't load suggestions just now — Notion did not answer. Try again in a moment, or type the value.
The database list is empty. Pick a connection first, at the top of the action. If it is still empty, nothing has been shared with the connection yet — see above.
The property list is empty. Choose the database first. If the database comes from the trigger rather than being picked, the list stays empty and you can type the column names instead — the automation works them out when it runs.
"That Notion database has no property called …" — the column name does not match. Notion column names are case-sensitive and easy to mistype, and renaming a column in Notion does not update rules that name the old one. The message lists the columns the database actually has.
"Notion computes … itself." Formula, Rollup, Created time, Last edited by and ID columns are worked out by Notion. Nothing can set them, including you, by hand.
"… is a checkbox — use true or false." Checkbox columns take true or false. An empty value leaves the column alone rather than unticking it, so say false if you mean unticked.
"That Notion database has more than one data source." Newer Notion databases can hold several sets of records. InfraNest will not guess which one you meant — pick the one you want from the database list instead of pasting the database's link.
"Notion refused this because the connection does not have that capability." Commenting is a separate permission from writing pages, and it is set on the connection in Notion's developer portal rather than here. Open the connection there and check its capabilities.
#What InfraNest keeps
Notion doesn't send InfraNest anything by itself: InfraNest only reads and writes when you or an automation ask it to.
- Published and linked pages — the address and title of each page a review or a postmortem was written to, and for a page you linked with Link a write-up made elsewhere, its title, its Status when the database has one, and who edited it last and when. Never a page's text.
- Postmortems settings — the database and which incidents, while the switch exists; for 30 days after a disconnect, so it can be offered back.
- Run history — when an automation with a Notion step runs, its run is kept for 90 days. Only members whose role can edit automations can see what it did. Everyone else sees that a run happened and whether it worked.
Was this article helpful?
Thanks for your feedback!
Thanks, this goes straight to the docs team.