This observability checklist asks one question of a business application that already runs: if it failed tonight, could your team explain why? It has ten checks. Every check scores 0, 1 or 2 against evidence that a person can open, which gives a total out of 20. The list covers one running application, such as a customer portal or an order system. Data pipelines and AI models need lists of their own. If the term is new, read a short definition of observability first. In plain words, it is how well a team can tell what goes on inside a system from the records it leaves.
Last reviewed 2026-11-08 by Manish Sharma.
We wrote it for IT heads, application owners and operations leads in mid-size firms across India and the GCC. Score one application at a time, and keep each set of scores with its date.
Scoring Rules for This Observability Checklist
Score each check from evidence and from nothing else. A person has to be able to open the record, read its date and see what it covers.
A 2 needs dated evidence that you can open today, from the last 90 days, covering the whole application. A 1 means some evidence exists, yet it reaches only part of the application or is older than 90 days. A 0 means there is no evidence, or there is only someone’s word that the thing is in place.
Use N/A only for a check that has no meaning for this application. For example, a single service with no outside calls has no request to follow across services. Check 2 then drops out, and you score out of 18.
Choose a recent incident, or one key journey such as login or payment, and score every check against it. The application owner gives the marks. After that, someone from another team opens each piece of evidence. If that person finds nothing, the mark falls to 0.
Log retention shows how the marks work. A written retention period that covers all of the application’s logs, and that the owner confirmed this quarter, earns 2. If the period covers the web tier but leaves out the background jobs, it earns 1. A period that someone remembers agreeing in a meeting earns 0.
The observability checklist has no pass mark and no target total. Instead, the score shows where evidence is thin, and the owner decides what to fix first. Signisys suggests the marks, the 90-day window and the N/A rule, and your firm can change any of them.
Observability Checklist: Can the Team Follow One Request?
Checks 1 and 2 ask whether the team knows which journeys matter and can follow one request through them. Every later check leans on these two. A log search or an alert means little without a journey to tie it to.
| No. | Check | Evidence to open | Scores 2 when | Who opens it |
|---|---|---|---|---|
| 1 | Key journeys listed | A written list of the journeys users care about, for example login, search and payment, with the outside services each one calls. | Each journey on the list has a named owner, and its list of outside services matches what runs today. | A business user reads the list and says if a journey they rely on is missing. |
| 2 | One request, one trace | A trace for the sample request that shows a single request ID across services and queues. | The same ID appears at every hop, including queues and calls to outside services. | Someone from another team opens the trace without help from its builder. |
A request ID is a label that travels with one request, and every service it touches records the same value.
The W3C publishes the Trace Context recommendation as a standard way to pass that context between services. A shared standard helps when a request crosses into a supplier’s system. If both sides read the same header, the trace stays in one piece.
A trace that stops at the first queue earns 1 on check 2, even if every service before the queue looks complete. Also look at the list from check 1 while you score check 2. A journey with no trace at all pulls check 2 down to 1, however good the traces on the other journeys are.
Can the Team Read What Happened?
Checks 3 and 4 ask whether the records exist to read a failure after the fact. They also ask whether anyone wrote down what normal looks like. An observability checklist that skipped targets would leave the team with logs but no line to judge them against.
| No. | Check | Evidence to open | Scores 2 when | Who opens it |
|---|---|---|---|---|
| 3 | Logs in one place | A search for the sample’s request ID across all of the application’s logs, plus the written retention period. | Every service writes to one searchable store in one shared format, and a written retention period covers all of them. | A person from support runs the search on their own. |
| 4 | Written targets | The written speed and error targets for each key journey, with the owner’s name and a date. | Each journey from check 1 has both targets, and its owner confirmed them inside the window. | The journey owner from check 1 reads the targets back. |
A target is a written line such as “search answers within two seconds for 95 in every 100 requests, and fewer than 1 in 100 fail”. We made those figures up for the example, and your owner sets the real ones. Check 4 asks only whether targets exist and have an owner. It does not score the resource readings behind them.
If the logs sit in one place but each service writes its own format, check 3 earns 1. A search still finds lines, but reading them across services then needs a person who knows every format. Likewise, a store with no written retention period earns 1, even when the search works well.
Key Takeaway Logs show what happened, and written targets show whether it was normal.
Observability Checklist: Does the Right Person Hear It?
Checks 5 to 7 look at the moment something goes wrong. They ask whether a person hears about it and can see what changed. Check 7 then asks whether more than one team looks at the same picture.
| No. | Check | Evidence to open | Scores 2 when | Who opens it |
|---|---|---|---|---|
| 5 | Alerts reach a person | The list of alert rules with an owner and a runbook link for each, plus one alert from the window that reached its owner. | Every rule has a named owner and a runbook, and alerts go to a person or an on-call rota instead of a shared inbox. | The last alert’s owner shows where it landed. |
| 6 | Releases on the graphs | The dashboard for one key journey, with markers for the releases in the window. | Each release from the window shows as a marker beside the graphs, including hotfixes and configuration changes. | Someone outside the release team matches the markers against the release log. |
| 7 | Shared dashboards | One dashboard per key journey, plus its view history or a dated meeting note that used it. | Each journey has a dashboard, and more than one team opened it during the window. | The operations lead reads the view history. |
A runbook is a short written note on what to check first and whom to call. If even one rule sends its alerts to a shared inbox, check 5 earns 1 at best.
Check 6 matters during an incident, when the first question is what changed. A marker beside the graph answers that without a search through chat threads. For check 7, a dashboard that only its builder opens earns 1. One that support and the business owner also open earns 2.
Can the Evidence Be Trusted Next Quarter?
Checks 8 to 10 ask whether the records are safe to keep and whether the monitoring still works. This part of the observability checklist looks past today’s incident to the next audit and the next quarter.
| No. | Check | Evidence to open | Scores 2 when | Who opens it |
|---|---|---|---|---|
| 8 | Access and personal data | The access list for logs and traces by role, and a sample of real log lines from the window. | Access follows job roles, and the sample holds no passwords, tokens or personal data in clear text. | Someone from security, or the data owner, reads the sample. |
| 9 | Tested by someone else | A dated record of a planted fault, for example a stopped service, and how someone found it. | A person who did not build the monitoring found the fault from alerts and dashboards alone, inside the window. | The person who planted the fault checks the record. |
| 10 | Dated review | Notes or a ticket from the last review of alerts, targets and dashboards, with an owner for each change. | A review took place inside the window, and each change it agreed has an owner and a date. | The application owner reads it with one person from another team. |
Personal Data in the Log Sample
On check 8, read real values instead of field names.
A field called user_id looks harmless until the sample shows an email address in it. In this checklist, any personal data in the sample sets check 8 to 0, whatever the access list shows.
OWASP’s logging cheat sheet names access tokens and sensitive personal data among the items to remove, mask, hash or encrypt before they reach a log. It also lists names, telephone numbers and email addresses as data that may need special handling before an event is recorded.
Firms in India also face a duty under the Digital Personal Data Protection Act of 2023, in section 8(5). Under it, a data fiduciary has to protect the personal data it holds or controls, by taking reasonable security safeguards to prevent a breach. The section does not mention logs. However, personal data that lands in a log is still data the firm holds. Your legal adviser can say how the section applies. In the GCC, check the local rules for the country where the data sits.
Reading Your Observability Checklist Score
Read the four area subtotals before the total. Two applications can both score 12 and still need different fixes. An observability assessment that reports one number alone hides the weak area.
A Worked Example, Invented for Illustration
We invented this application, its scores and its team, and they come from no real client. Take an order-booking application at a distributor, scored against last month’s slow-checkout incident. Checks 1, 3, 4 and 6 earn 2 each. Checks 2, 5, 7 and 10 earn 1 each, while checks 8 and 9 earn 0. The recount is 8 + 4 + 0 = 12 out of 20.
The area subtotals tell more than the total.
| Area | Checks | Subtotal | What the evidence showed |
|---|---|---|---|
| Follow one request | 1 and 2 | 3 of 4 | The trace stops at the order queue. |
| Read what happened | 3 and 4 | 4 of 4 | Both checks earn 2. |
| The right person hears it | 5 to 7 | 4 of 6 | One rule still mails a shared inbox, and only the build team opens the dashboard. |
| Evidence you can trust | 8 to 10 | 1 of 6 | Only the review earns a mark. |
Start with the last area. In particular, the 0 on check 8 came from a sample with customer phone numbers in clear text. That finding goes to the data owner the same week, before any other fix on the list. When your own first or second area shows a 0 or 1 instead, the parts are not in place yet. In that case, a guide to the order to set each part up fits better than a rescore.
Rescore After These Four Events
Score the application again after any of these events:
- a major release;
- a new service or a new outside dependency;
- a serious incident;
- a change of application owner.
If none of them happens, rescore each quarter, which is a Signisys suggestion. After an event, you can rescore only the checks it touches. For example, a new dependency touches checks 1 and 2, while a new owner touches checks 1, 4, 5 and 10.
Key Takeaway Each score records the evidence on one date, and it makes no promise about the next failure.
What a Score of 20 Leaves Unanswered
A full score means the team has evidence for every check on one application. Even so, the observability checklist leaves several questions to other work. It does not judge availability design, failover or tool choice, and it does not cover security event monitoring. It also leaves open how far past fixed alerts a firm should go, which a six-factor decision guide for IT leads covers. Server, network and data store readings belong on a separate resource checklist. Why repairs still run long when the evidence exists is a separate question as well. For that, read why a fix drags on for hours.
Call in a specialist if nobody owns the alerts or if the check 8 sample turns up personal data. The same goes when no one can follow a request through a supplier’s service. For the wider picture of this work, see application monitoring and faster troubleshooting.
Signisys provides these services, which gives us an interest in your call. The ten checks work without us. Want a second person to open the evidence with you? Look at observability built into modernization work or talk to our DevOps and IT automation team. No charge, with a fixed scope.
Observability Checklist FAQ: Questions From IT Teams
Does this observability checklist cover data pipelines or AI models?
Can a team with only basic uptime checks score above zero?
Can a supplier score the observability checklist for us?
What should happen if a log holds personal data during the check?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.