Asking Pindot good questions: a field guide for on-call engineers

You do not need a query language to use Pindot. You ask in the words you would use on the bridge, and Aladdin, Pindot's assistant, reads across your sources and answers with the records it relied on. That said, the way a question is put makes a real difference to how quickly it gets to the cause. This guide collects what works.

Name the symptom, the system and the time

The single biggest improvement is to say what you are seeing, where, and since when. Pindot can search everything, but a question with a system and a window tells it where to look first.

The second question names a service, a symptom and a start time. The answer that comes back can line up the error rate, the database log and the change records around that minute, instead of surveying the whole estate.

Start from what you are looking at

Often the best question is the one the console asks for you. Pindot lets you hand context straight to Aladdin rather than retyping it.

• On the Signal Dashboard, drag across a stretch of a source's chart to ask about exactly that window.
• On an alert, choose “Ask Aladdin about this” to start from the alert itself.
• On a new chat, the suggested starting points cover the common cases: explain this incident, find related events, scan for anomalies, or show the numbers.

Choose which sources it reads

By default a question reads all the sources you have access to. When you already know the problem lives in one place, narrow it with the sources selector in the question box. A narrower question is faster to answer and easier to check. Widen it again when you want Pindot to look for something that changed elsewhere.

Follow up in the same conversation

The first answer is rarely the last question. Stay in the same chat, so the whole investigation sits in one thread that anyone joining the call can read from the top, and ask the questions an experienced engineer would ask next.

1. What changed in the hour before this started?
2. What else happened around the payments database at the same time?
3. Is anything else unusual in the last 24 hours, or is this the only spike?
4. Show the error volume by source for the last six hours.

Read the answer like a reviewer

Every answer cites the records it rests on. Before acting on it, open the citations behind the claims that matter most for your next step. If the answer says a release lowered a pool size, the change record should say so. This takes seconds and it is the habit that makes the whole team trust what Pindot says.

• Check the evidence count. An answer resting on records from three sources is stronger than one resting on a single log.
• Read the confidence level, and treat a lower one as a lead to confirm rather than a conclusion.
• Look for a note about sources that could not be read. If one of them matters to your question, fix the source or ask again once it is back.

Hand the finding to the team

Once the cause is clear, share it where your team works. With Jira switched on by an administrator, Pindot drafts a ticket from its own answer with the evidence attached, and you review the draft before anything is filed. With Slack switched on, findings are posted with their evidence. Either way, the record of where Pindot looked stays in the audit trail for the review.

What Pindot will not do

It is worth knowing the limits, so nobody waits for something that will not happen. Pindot reads your systems and never changes them, so it will not restart a service or roll back a release. It answers within the access you have, so it will not show you data from a source your team has not been granted. And it never presents a partial answer as a complete one. The decisions stay with you. Pindot's job is to make sure they are made on evidence.