How Do You Search Logs for a Failed Refresh?
From the earlier reference collection. Read the current software blog.
Narrow logs by source identifier and time window, then read surrounding events to understand the failure sequence.
Make the search narrow enough to answer
A refresh job may process several public sources in one run. Searching only for the word error can mix unrelated failures and retries. Start with the source identifier used by the job, then limit results to the period when the refresh was expected to run. For a plain text log, rg 'source=city-feed' refresh.log is a quick first filter. If timestamps use a consistent sortable format, a time-window filter can then narrow the matches further.
Prefer a stable identifier over a display name. A source may be renamed in the interface while its internal key remains constant. If the log format uses structured JSON, query the parsed source_id and timestamp fields rather than matching arbitrary substrings.
Preserve time boundaries
Write down the time zone used by the log before comparing entries with a scheduler or operator report. A timestamp without an offset can be ambiguous during daylight-saving transitions or when the job runs in a different region. Specify inclusive and exclusive bounds consistently—for example, from 10:00 inclusive up to 10:15 exclusive—so repeated searches cover the same interval.
If the logs are rotated, include the relevant archived file. A refresh that begins just before midnight may have its startup message in one file and its failure in the next. Likewise, a retry may happen outside the original window. Begin with a tight range, then expand it enough to capture the complete attempt.
Read surrounding context
A matching error line rarely tells the whole story. Use rg -n -C 4 'source=city-feed' refresh.log to show nearby lines, or inspect a few lines before and after the specific failure. Look for the start event, the operation being attempted, a response or parser message, any retry, and the final job outcome. Those details can distinguish a connection problem from a malformed input or a local write failure.
For example, an HTTP status message followed by a retry suggests a different investigation than a parser exception after a completed download. Do not infer the cause from the word timeout alone; establish which operation timed out and whether a later attempt succeeded.
Turn the search into a useful record
Summarize the source, time range and time zone, attempt identifier, first clear failure, and final outcome. Redact tokens, private URLs, and personal data before sharing log excerpts. Keep the relevant context, because a bare error string loses the sequence needed for diagnosis.
For recurring work, structured logs with source IDs, timestamps, and job IDs make these searches more precise. A command-line filter is an investigative tool; good fields in the underlying events are what let it isolate one failed refresh without blending it with other activity.