Haruno Knowledge base

Web search

See how many web searches the apps ran and how they ended, and choose which search services handle them.

  • Operator consoleAvailable

When Haruno needs something from the web, the app asks the service to run a search. Web Search shows every one of those searches and how it ended. Use it to answer "is web search working?" and "why did a search fail?".

A day of searches. Most are served. A short burst was limited and a rough patch failed.
The Web Search page: summary cards, a row of outcome counts, a stacked bar chart of searches per hour, a table of the busiest keys and a table of recent failures

What you see

  • The time buttons run from 6h to 1y. The page opens on 24 hours.
  • Cards: Searches, With results (the share that came back with results), Rate-limited, Failed, No results and p95 latency. That last one means 95 out of 100 served searches were at least this fast.
  • A row of outcomes with a count for each. Point at an outcome for its meaning.
  • A chart of searches per hour, or per day for long windows. Each bar is stacked: with results, no results, rate-limited, failed.
  • Busiest keys: the keys that ran the most searches, with how many were limited or failed.
  • Recent searches: the latest 50. It shows when, which key, the outcome, which service answered, the reason a backup was used, the status code and the time taken.
  • Recent failures: the latest searches that did not work, with the detail the service recorded.

The page never records or shows what was searched for, or what came back.

What the outcomes mean

OutcomeMeaning
With resultsServed, with results
No resultsServed, but nothing was found. A relevance problem, not a fault
Caller hung upThe app gave up before the search finished
User capThe person reached their own search limit
Search capacityOur search capacity was busy, so no new request was sent for that attempt
Budget exhausted, Usage windowThe person's allowance or rolling limit was used up
Team cap (legacy)An older shared limit refused it
Provider throttledThe search service limited it
Provider unavailable, Provider errorThe search service failed or did not answer
No provider keyNo search service is set up on the server

The cards group these into three: served, Rate-limited and Failed. An outcome the page does not know yet is shown under its own raw name.

The search services

At the top of the page, Search services chooses which service answers first (Primary service) and which one takes over when the first one fails in a way a backup can fix (Fallback service). The fallback can be Disabled. The two cannot be the same.

Under the menus the page says whether each service is Configured or Not configured. That is not a live health check. A configured service can still be down.

To change them:

  1. Pick the primary and the fallback.
  2. Press Save services.

The change applies to new searches.

If someone else saved first, the page says "Settings changed" and asks you to press Reload services before you save again. Only a super admin can save. Everyone else sees the choice but cannot change it.

What a person in support or sales can ask an operator

  • "A customer says web search failed. Is it just them?" Look at Recent failures, and at Busiest keys to see whether their key is limited.
  • "Is search healthy overall?" Read With results and the chart.
  • "Why did a search come back empty?" Check whether the outcome was No results. That means the search worked and found nothing.

Last updated · PR #2944 · View this version on GitHub

History (1 version)
  1. Internal knowledge base for staff: site, reader keys, assistant, 197 pages and the PR rule (#2944)
    PR #2944Commit a2a7836The page at this version
    What changed
    @@ -0,0 +1,63 @@
+---
+title: Web search
+summary: See how many web searches the apps ran and how they ended, and choose which search services handle them.
+feature: ops-web-search
+covers:
+  - web/monitoring/components/WebSearchPage.tsx
+  - web/monitoring/components/WebSearchSettings.tsx
+  - server-dotnet/src/Haruno.Server/Controllers/AdminWebSearchController.cs
+---
+
+When Haruno needs something from the web, the app asks the service to run a search. **Web Search** shows every one of those searches and how it ended. Use it to answer "is web search working?" and "why did a search fail?".
+
+<Shot src="/m/d55815120edf-ops-web-search-dark.png" alt="The Web Search page: summary cards, a row of outcome counts, a stacked bar chart of searches per hour, a table of the busiest keys and a table of recent failures" caption="A day of searches. Most are served. A short burst was limited and a rough patch failed." />
+
+## What you see
+
+- The time buttons run from **6h** to **1y**. The page opens on 24 hours.
+- Cards: **Searches**, **With results** (the share that came back with results), **Rate-limited**, **Failed**, **No results** and **p95 latency**. That last one means 95 out of 100 served searches were at least this fast.
+- A row of outcomes with a count for each. Point at an outcome for its meaning.
+- A chart of searches per hour, or per day for long windows. Each bar is stacked: with results, no results, rate-limited, failed.
+- **Busiest keys**: the keys that ran the most searches, with how many were limited or failed.
+- **Recent searches**: the latest 50. It shows when, which key, the outcome, which service answered, the reason a backup was used, the status code and the time taken.
+- **Recent failures**: the latest searches that did not work, with the detail the service recorded.
+
+The page never records or shows what was searched for, or what came back.
+
+## What the outcomes mean
+
+| Outcome | Meaning |
+|---|---|
+| With results | Served, with results |
+| No results | Served, but nothing was found. A relevance problem, not a fault |
+| Caller hung up | The app gave up before the search finished |
+| User cap | The person reached their own search limit |
+| Search capacity | Our search capacity was busy, so no new request was sent for that attempt |
+| Budget exhausted, Usage window | The person's allowance or rolling limit was used up |
+| Team cap (legacy) | An older shared limit refused it |
+| Provider throttled | The search service limited it |
+| Provider unavailable, Provider error | The search service failed or did not answer |
+| No provider key | No search service is set up on the server |
+
+The cards group these into three: served, **Rate-limited** and **Failed**. An outcome the page does not know yet is shown under its own raw name.
+
+## The search services
+
+At the top of the page, **Search services** chooses which service answers first (**Primary service**) and which one takes over when the first one fails in a way a backup can fix (**Fallback service**). The fallback can be **Disabled**. The two cannot be the same.
+
+Under the menus the page says whether each service is **Configured** or **Not configured**. That is not a live health check. A configured service can still be down.
+
+To change them:
+
+1. Pick the primary and the fallback.
+2. Press **Save services**.
+
+The change applies to new searches.
+
+If someone else saved first, the page says "Settings changed" and asks you to press **Reload services** before you save again. Only a super admin can save. Everyone else sees the choice but cannot change it.
+
+## What a person in support or sales can ask an operator
+
+- "A customer says web search failed. Is it just them?" Look at **Recent failures**, and at **Busiest keys** to see whether their key is limited.
+- "Is search healthy overall?" Read **With results** and the chart.
+- "Why did a search come back empty?" Check whether the outcome was **No results**. That means the search worked and found nothing.