Confidence Score

The confidence score is a number from 0 to 100 that expresses how likely an IP address is to be malicious. It is not a report count and not an average rating: it combines how many independent sources reported the address, how recently, how severe the reported behaviour was, and whether any of the reports came from a verified honeypot. Every API response that contains abuseConfidencePercentage carries this number.

How the score is built

Four components are added together, each capped so no single signal can carry a score on its own. A honeypot bonus is then added, and the total is limited to 100.

Reporter diversity

Reports from different sources count for far more than repeated reports from one source. An address reported by ten different sites is treated very differently from one reported ten times by a single site, even though both have ten reports.

Two constraints enforce this:

• Fewer than 5 effective reports caps the score at 49.
• Fewer than 10 effective reports caps the score at 74.
• A single reporter with more than one report caps the score at 60.

"Effective reports" counts honeypot reports twice, because a honeypot has no legitimate traffic to confuse with an attack.

Time decay

Reports lose weight as they age, on a 30-day half-life. An address that stops attacking therefore falls out of the blacklist on its own, without anyone filing a removal request.

The weight never reaches zero. A long history of abuse stays faintly visible, which is why an address with a years-long record recovers more slowly than one with a single recent incident.

Honeypot reports

A honeypot server has no real users, so every request it receives is unsolicited by definition. That makes its reports unusually clean, and they are weighted accordingly: they count double toward the effective report count, they add a bonus of up to 25 points, and they decay more slowly than ordinary reports.

The bonus is still gated on diversity. A single honeypot reporting the same address repeatedly earns a reduced bonus, and beyond a threshold it incurs a penalty — otherwise one noisy sensor could move the score for the whole network. See Honeypot Server for how to run one.

Burst aggregation

Repeated reports for the same address from the same reporter within a short window are merged into a single record with an attack counter. A brute-force run producing 500 failed logins in two minutes therefore registers as one sustained incident rather than 500 separate pieces of evidence.

Reading the breakdown from the API

Adding verbose=true to a /check request returns the individual components alongside the final score, which is the fastest way to understand why an address scores what it does.

{
  "data": {
    "ip": "203.0.113.42",
    "abuseConfidencePercentage": 75,
    "confidenceBreakdown": {
      "reportScore": 12.0,
      "diversityScore": 8.0,
      "recencyWeight": 10.5,
      "severityWeight": 9.3,
      "honeypotBonus": 15.0,
      "maxConfidence": 100,
      "constraintReasons": []
    },
    "debugInfo": {
      "reportCount": 8,
      "uniqueReporters": 4,
      "honeypotReportsCount": 3,
      "effectiveReportCount": 11,
      "timeDampeningFactor": 0.85
    }
  }
}

constraintReasons is the field to check when a score looks lower than the report count suggests: it names the cap that applied. See the API Reference for the full response format.

Choosing a threshold

The right cut-off depends on what happens when it is crossed. Blocking a paying customer costs more than letting one scanner through, so the threshold should rise with the severity of the action.

The community blacklist uses 75 as its inclusion threshold; the per-service network lists use 90, because a kernel-level drop gives the visitor no way to appeal. See Network-Level Blocking.

If a score looks wrong

Scores fall on their own as reports age, so an address that has stopped attacking needs no intervention. For an address listed in error — a shared NAT gateway, a mail server that was briefly compromised, a scanner run with permission — see IP Delisting.

Last updated: 13. August 2026 · Maintained by the ReportedIP team