Skip to content

Runbook

Write down how to run and fix a service: checks, steps, rollback, who to call and how to know it worked.

Fill it in and preview

Runbook

Procedure: Restart the payments worker
Service: Customer payments API
Owner: Platform team
Last reviewed: 3 August 2030

1. When to use this runbook

Use when payments are queued for more than 10 minutes and the dashboard shows the worker as down.

2. Access and tools you need

Read access to the monitoring dashboard
Shell access to the production jump host
Member of the on-call group

3. Checks before you start

1. Confirm the alert is real: open the Payments dashboard and check the queue size.
2. Check the status page for a provider outage.
3. Tell the incident channel you are starting.

4. Steps

1. Log in to the jump host.
2. Run the service restart command for the worker.
3. Wait 2 minutes.
4. Check that the queue size is falling.
5. Check three recent payments completed.

5. How to confirm it worked

Queue under 50 and falling, no new errors for 10 minutes.

6. If it does not work

Stop the worker, switch the service to the previous release, and escalate to the payments engineer.

7. Who to call next

Who How to reach them
Payments engineer on call via the paging tool
Platform lead +00 000 000 0000
Customer support lead, if customers are affected support channel

8. Warnings

Never restart both workers at once. Do not clear the queue by hand.

9. Afterwards

Write a note in the incident log with times and what was done. Raise a ticket if the cause is not known.

Templates are a careful starting point, not legal advice. Where the law matters, check what applies where you are.

IT and projects

What this template is for

A runbook for operating and fixing a service: owners, checks, step by step procedures, rollback, escalation and contacts, so anyone on call can act.

It is free to fill in online, needs no account, and downloads as a Word document or a PDF. See all IT and projects templates

IT and projects

What you fill in

The form asks for 13 details. The document fills itself in as you type.

  • Service or system

    For example: Customer payments API

  • Procedure name

    For example: Restart the payments worker

  • Owning team

    For example: Platform team

  • Last reviewed

    For example: 3 August 2030

  • When to use this runbook

    Say what alert or symptom sends someone here.

    For example: Use when payments are queued for more than 10 minutes and the dashboard shows the worker as down.

  • Access and tools needed

    One per line.

    For example: Read access to the monitoring dashboard Shell access to the production jump host Member of the on-call group

  • Checks before you start

    Numbered, one per line.

    For example: 1. Confirm the alert is real: open the Payments dashboard and check the queue size. 2. Check the status page for a provider outage. 3. Tell the incident channel you are starting.

  • Steps

    One action per line, exact commands where safe.

    For example: 1. Log in to the jump host. 2. Run the service restart command for the worker. 3. Wait 2 minutes. 4. Check that the queue size is falling. 5. Check three recent payments completed.

  • How to confirm it worked

    What you will see when it is fixed.

    For example: Queue under 50 and falling, no new errors for 10 minutes.

  • If it does not work (rollback)

    How to undo or fall back.

    For example: Stop the worker, switch the service to the previous release, and escalate to the payments engineer.

  • Who to call next

    One row for each contact.

    For example: Payments engineer on call | via the paging tool Platform lead | +00 000 000 0000 Customer support lead, if customers are affected | support channel

  • Warnings (optional)optional

    Things that make it worse.

    For example: Never restart both workers at once. Do not clear the queue by hand.

  • Afterwards (optional)optional

    For example: Write a note in the incident log with times and what was done. Raise a ticket if the cause is not known.

IT and projects

What is inside

The parts of this document, in order.

  1. 11. When to use this runbook
  2. 22. Access and tools you need
  3. 33. Checks before you start
  4. 44. Steps
  5. 55. How to confirm it worked
  6. 66. If it does not work
  7. 77. Who to call next
  8. 88. Warnings
  9. 99. Afterwards

Templates

How it works

  1. 01

    Fill in

    Type your details in the form. The document fills itself in as you type; click any gap to jump to its field.

  2. 02

    Check

    Read it through. Gaps you have not filled stay marked, so nothing goes out half done.

  3. 03

    Download

    Save it as a Word document to edit further, or as a PDF to send or print.

Make it yours with AI

Open it in the chat and ask for changes: shorter, firmer, another situation, another language.

Adapt it with nerix

IT and projects

Questions people ask

What details does this template ask for?

The form asks for 13 details, starting with Service or system, Procedure name, Owning team, Last reviewed, When to use this runbook. 2 more are optional.

Can I download this template as Word or PDF?

Yes. When you have filled in the form, save it as a Word document to keep editing, or as a PDF to send or print. It is free and needs no account.

Is what I type sent anywhere?

No. What you type stays in your browser while you fill in the document. It only goes to nerix if you choose to open the template in the chat.

Are these IT and project templates free?

Most are. Fill in and download them for free as Word or PDF, with no account. A few longer documents are premium: free to fill in, paid once to download, and marked with their price.

Does a security policy make us secure?

No document does that alone. A policy helps when it matches what people really do, so keep it short, explain it to your team and review it every year.

Is a project charter only for large projects?

No. A small project benefits too, because one page that names the goal, the limits and the decision maker prevents most arguments later.