Salience

See which pages are returning errors before anyone reports them.

Salience reads your CDN or server access logs and reports error spikes, slow responses and traffic drops for every path, with the status codes and clients behind each one. Alerts go out by email, Slack and webhook.

Connect a log sourceExplore the demo

Free plan, no card, nothing added to your pages. All 16 alerts by email and Slack start on the Solo plan at $19 a month.

The Dashboard for demo-site.example, last updated 10:50:12. Site Health, last 30 minutes, baseline established for 5 of 6 metrics: Traffic 808, Elevated; 5xx errors 414, Elevated, up from 2 while the baseline was learning; Bots 51%, Elevated; Crawlers 46, Elevated; Latency 0ms, Normal; 404s 2.5%, High. Active incidents to review, newest first: 5xx spike on /api/products: 412 responses returned 503 since 14:06. Single /wp-login.php probe from AU IP returned 403; verification shows endpoint is protected. Single /wp-login.php probe from AU IP returned 403; verification shows endpoint is protected. Single /wp-login.php probe from AU IP returned 403; verification shows endpoint is protected. Showing 3 of 5 active, unacknowledged incidents.

Log sources and alert destinations
  • Cloudflare
  • Vercel
  • AWS
  • Kinsta
  • Slack

Every path is compared with its own history

Salience learns what normal looks like for each path and section of your site from your own traffic, and alerts you when errors, response times or request volume move away from it. Each alert names the paths and clients involved.

  • 4xx and 5xx errors rising on a path or section
  • Response times changing on a path, where your log source records timing
  • Traffic falling towards zero, or surging on one route
  • Redirect loops and redirect chains
  • One address sending far more requests than usual

Status Codes on demo-site.example, last 24 hours: 24,447 2xx Success (71.6%), 6,416 3xx Redirect (18.8%), 3,272 4xx Client Error (9.6%), 28 5xx Server Error (0.1%). Status codes over time in half-hour buckets.

What this looks like in practice

Customer exampleUK comparison site

Login requests took the site down. Infrastructure alerts reported high CPU, and SEO tooling had tagged the traffic as human.

114,838 login requests from one address

  1. 6 hoursA single datacentre IP sent 114,838 POST requests to /blog//wp-login.php, rotating more than twenty browser user agents.
  2. MonitoringInfrastructure alerts reported high CPU load.
  3. First windowSalience flagged the burst within the first five-minute detection window, with the source IP, the path and a label of a scraper rotating user agents.

The address was rate-limited at the CDN. Salience supplied the evidence, and the response was carried out in the customer's own infrastructure.

Scenarioin-house technical SEO

I deployed sitemap changes yesterday. No idea if Googlebot has seen them. Search Console won't tell me for 48 hours.

A Friday URL change caught before Monday

  1. Fri 16:00A URL-structure deploy goes out with the redirect rules.
  2. Sat 08:00Salience alerts: Googlebot has requested 1,247 of the old URLs and received 404s, because the redirect rules missed one pattern.
  3. SatThe pattern is added and the redirects tested before Monday's traffic.

The same 404s would have reached Search Console on the Tuesday, after Google had begun dropping the URLs.

Salience works alongside the monitoring you already run

An APM watches the application from the inside, an uptime monitor checks one URL on a schedule, and a CDN dashboard counts requests on one zone. Salience reads the access logs those layers already produce and reports what every request received, per path and per client, compared with your own baseline. Alerts go to email, Slack and webhooks, and the same data reaches your existing tools through the API, the CLI and the MCP server.

Site Checks run every night on your last seven days of traffic

Twenty-one checks look for the problems that hurt search visibility and go unnoticed in day-to-day monitoring. Each check gets a verdict of pass, warn or fail, with the numbers behind it, a 30-day history and a link to the page where you fix it. When a verdict changes, an alert goes out.

  • The crawler access checks confirm that verified Googlebot is not blocked or rate limited, that robots.txt is served reliably and is not fetched more often than a cached file should be, that Googlebot has fetched your sitemap in the last seven days and received a 200, how much of each AI crawler's traffic is blocked, and whether an llms.txt file is present.
  • The security hygiene checks confirm that probe paths such as /.env and /.git/config do not return 200, how much of the traffic claiming to be Googlebot or Bingbot fails verification, whether the original visitor IP is visible in your logs, and what share of bot traffic is unidentified.
  • The serving quality checks cover server errors and redirects served to crawlers, possible soft 404 responses, response times to Googlebot, whether crawlers are being placed into A/B tests, and whether robots.txt and sitemap.xml are delivered as static, cacheable files.

Site health shows whether data is flowing and how the last hour compares with normal

The health view puts the last hour's traffic, error rate and response time against a rolling baseline built from your own history, with a status for each and a note on how mature the baseline is. It also confirms that requests are still arriving from your log source, so a quiet chart is never mistaken for a quiet site.

  • Traffic, errors and response time against their own baseline, each marked normal, warning or critical
  • Whether the log source is still delivering, and whether the feed is configured correctly
  • The alerts active right now, with an hourly history for each metric
  • The slowest paths and the 404s crawlers keep hitting, scored and listed as recommendations with a next step
  • A live feed of requests as they arrive, filtered to errors

Every alert includes what you need to start investigating

Each alert lists the paths, status codes, clients and time window involved, with a short written note on what to check first.

  • The paths and site sections affected
  • Status codes before and after, per path
  • Source IPs, user agents and named crawlers, verified against published IP ranges where the provider publishes them
  • Request volume and time window, compared with your own history
  • What your CDN, WAF and application returned, including rate limits and rejections
  • Email for alerts above a severity you set, a daily digest for the rest, and Slack and webhooks for all of them

Tell a traffic flood from a busy day

A spike is measured against the path's own history, so a launch that doubles traffic and a flood that doubles it look different in the record. Salience reports where the extra requests came from and what your edge did with them, and leaves volumetric protection to your CDN.

  • Whether the spike came from one aggressive source or many addresses and networks
  • The paths and sections that took the load, ranked by request count and response time
  • Retries, visible as the same addresses repeating requests your site had already rejected or answered slowly
  • The 429 rate limits and 5xx failures your CDN, WAF and application returned while it lasted

Mark releases and migrations on the timeline

Site events mark deployments, migrations, campaigns and infrastructure changes on the traffic charts. Add them in the app or through the API, and every write made with an API key is recorded as an event too. When errors climb after a release, the chart shows the change and the event side by side.

Find pages that fail some of the time

Status Consistency lists pages that return 200 to some requests and 404 or 5xx to others, with a severity based on the share of failed responses, a status timeline, counts per status class and the time of the last failure. Exports add a consistency percentage and an impact score per URL. After a Site Crawler run, each page also shows what SalienceBot found there, so a live page that flips between 200 and 404 can be told apart from one that redirects or carries noindex.

How different teams use it

The same record of what your site returned answers a different question for each team.

On-call and platform engineering

Which path began returning 5xx, from what time and to which clients, before anyone opens the application traces.

Technical SEO

The 404s and 5xx served to verified Googlebot after a deploy, with the URLs listed, within the hour.

E-commerce operations

Checkout, search and collection pages watched against their own history, with rate-limited and failed requests counted per path.

Agencies and multi-site teams

Every client site in one account, each with its own baselines and alerts, and a shared read-only dashboard per client.

Keep your history and ask questions in plain English

Historical log files import alongside the live stream, deduplicated against anything already received and free of the monthly quota, so your baseline starts from real history. Anyone on the team can ask a question in words, and CSV exports, the API, the CLI and the MCP server carry the same data into your own tools.

  • Apache, Nginx and CloudFront logs, and exports from other log analysers, import with format detection
  • History kept from 30 days on Free to four years on Pro
  • Shared read-only dashboards for people outside the account

Import Logs on demo-site.example. Import jobs and current progress. Each job retains its own source dates. Import Historical Logs: Upload CloudFront or Apache/Nginx log files, or a log-analyser Events CSV, to analyse historical traffic data. Drag & drop log files, or click to browse (multiple files supported). Supported formats: CloudFront, Apache/Nginx, log-analyser Events CSV (.log, .txt, .csv, .gz, .zip). Supported formats: CloudFront standard/real-time logs, Apache/Nginx Combined Log Format, log-analyser Events CSV Auto-detection: We'll automatically detect the log format and parse the data Compressed files: .gz and .zip files are supported and will be decompressed automatically

Why not the tools you already have

Most web teams run an APM, an uptime monitor, a CDN dashboard and Search Console. Each answers a different question, and Salience sits alongside them.

APM (Datadog, New Relic)

What it shows
Traces, application metrics and errors from inside the code it instruments.
What Salience adds
What every request received at the edge, including requests the application never handled, with the client verified and each path compared with its own history.

Metrics dashboards (Grafana, CloudWatch)

What it shows
Time series you define, on the hosts and services you instrument.
What Salience adds
Findings per path and section worked out from the access log, with the paths and clients named in the alert and no query to write first.

Uptime monitors

What it shows
Whether one URL answered a scheduled check from outside.
What Salience adds
Every request from every client on every path, so a route failing for one section or one client is reported while the homepage check stays green.

CDN analytics

What it shows
Request and error counts on one CDN's zone, with a bot score per request.
What Salience adds
The same view for any CDN or server, per URL, with named crawlers verified against published IP ranges and history kept by plan.

Google Search Console

What it shows
Crawl errors as Google reports them, after a delay.
What Salience adds
The status your server returned to verified Googlebot on every URL, within the hour, joined to your sitemap.

Client-side analytics

What it shows
Human browser sessions collected by a tag.
What Salience adds
Every request as the server logged it, including bots, crawlers and visitors who never ran the tag.

Common questions

How is this different from an APM?

Salience reads the access log: every request that reached your CDN or server, with its path, method, status code, client address, user agent and size, and response time where the source records it. Status codes and volume are analysed per path and section against your own history. An APM covers the application internals and traces.

How quickly does an error spike appear?

Cloudflare, Vercel, Apache and Nginx deliver requests within seconds, CloudFront real-time logs arrive in seconds to minutes, and Kinsta logs are pulled every 15 minutes. Reports and detectors read the stream in fifteen-minute batches, so a spike is visible and alerted within about twenty minutes. Anomaly detection starts once about 24 hours of history has built up.

Can it detect a traffic drop?

Yes. Traffic falling towards zero against your own history is one of the detectors, per section, alongside surges on a single route.

Does it monitor 404 and 5xx responses?

Yes, continuously. Every status class from 2xx to 5xx is counted per path and section, and spikes are measured against your own history, so the threshold is what is normal for your site.

Does it report response times?

Where the source records them. CloudFront carries edge timing, and Apache and Nginx report response times once a timing field such as %D or $request_time is in the log format. Status, path, client, user agent and size are there on every source.

What do the nightly Site Checks cover?

Twenty-one checks, evaluated every night from your last seven days of traffic, in three groups. Crawler access covers Googlebot being blocked or rate limited, robots.txt reliability and fetch cadence, sitemap fetches, AI crawler access and llms.txt. Security hygiene covers sensitive-file responses, bot identity verification, original visitor IP visibility and the unidentified bot share. Serving quality covers server errors and redirects to crawlers, possible soft 404s, crawler exposure to A/B tests, and robots.txt and sitemap delivery and caching. Each verdict shows the evidence behind it and a 30-day history, a change in verdict sends an alert, and the verdicts are on the API, the CLI and the MCP server. Site Checks are included on every plan, Free included.

Are all requests ingested?

Every request that reaches the source, from humans and from bots, with no sampling by Salience. CloudFront real-time logs arrive at the sampling rate you configure in AWS, so keep it at 100% if you want every request.

Does it touch the origin or slow the site down?

Log collection adds nothing to your pages and no load to the origin. CDN sources need nothing installed, and Apache and Nginx use the open-source Vector agent, which reads the log file and sends it over HTTPS outside the request path. Six of the nightly site checks fetch your site directly as SalienceBot/1.0 from one fixed IP address, 18.132.26.88, a handful of requests to files such as robots.txt and sitemap.xml; they can be switched off in Website Settings. The Site Crawler runs only when you start it.

Can I mark a deployment on the timeline?

Yes, as a site event added in the app or through the API, with a date, time, title and a category such as deploy. Events overlay the traffic charts, so a change in errors or volume can be read against the release before it.

Can I import historical logs?

Yes. Apache, Nginx and CloudFront logs, and exports from other log analysers, upload with automatic format detection, deduplicate against anything already streamed, and do not count against the monthly request quota, so your baseline starts from real history.

Can alerts feed our existing workflow?

Yes. Alerts go out by email, Slack and webhooks, and the same data is available through CSV exports, the API, the CLI, the MCP server and shared read-only dashboards.

Which fields does Salience collect, and where is the data held?

Access-log fields: path, method, status, client address, user agent, size and, where recorded, timing and cache status. Request and response bodies are never collected. Data is held in AWS eu-west-2 (London), encrypted in transit and at rest, kept for the period your plan includes, and never shared between customers. A GDPR Article 28 DPA applies to every account.

What does the free plan include?

One website, 500,000 requests a month, 30 days of history, real-time analytics, bot and AI crawler detection, all 21 site checks, two email alerts, and the API, MCP server and CLI. Solo at $19 a month adds all 16 alerts by email and Slack, the sitemap and Search Console joins, log import and six months of history. Webhooks and shared dashboards start on Starter at $49. Every plan except Solo has unlimited users, and no card is needed to start.

Trust & data protection

Privacy and data protection

You are the controller

We process only on your instructions. GDPR Art. 28 DPA on every account, nothing to sign.

UK data residency

AWS eu-west-2 (London). Encrypted in transit (TLS 1.2+) and at rest (AES-256).

Server-side collection

No browser tracking script and no client-side pixel.

No sale, no pooling

Your logs are never sold, never used for advertising, never shared between customers. DPA, sub-processor list and security overview available.

Related

Your access logs already record which pages failed and when.

Free plan, no card, nothing added to your pages. All 16 alerts by email and Slack start on the Solo plan at $19 a month.

Connect a log sourceExplore the demo