A self-hosted Papertrail alternative

Nobody leaves Papertrail because it stopped working. They leave because the bill grew faster than the traffic.

Papertrail is a hosted log service, now part of SolarWinds. Point syslog at their endpoint and search your logs in a browser. It is old, it is easy, and for a lot of teams it was the first log tool that did not require running Elasticsearch.

Three things send people looking for an alternative. The bill scales with log volume. Retention is shorter than they want. The logs sit on someone else’s disk.

The core difference

Papertrail is a service you rent. Central Logging is a binary you own.

That one distinction drives everything below.

Pricing model, not price

Ask which direction the cost moves as you grow. Not which is cheaper this month.

Papertrail prices by log volume per month, with retention tied to plan tier. Check their current pricing for numbers — they change. The structure is the point: your bill is a function of how much you log.

That leads somewhere predictable. You add a service. Logging goes up. The bill goes up. Someone proposes logging less to save money. Volume pricing makes that proposal sound reasonable, and it is a bad trade.

Central Logging costs $187 once. Log volume hits your disk, not your bill. A chatty new service costs you gigabytes. Gigabytes are cheap.

The trade is real, so here it is plainly. You swap a recurring bill for a server you have to keep running. If you do not already run a server, do not make that swap.

Data residency

Your logs hold internal hostnames, request paths, user identifiers, stack traces, and whatever else your application decided to print. Papertrail stores all of it on a third party’s infrastructure.

Most teams are fine with that. For others it turns into a compliance conversation, a vendor security review, or a DPA negotiation.

Central Logging keeps the logs on a disk you control, behind your firewall. No telemetry, no call-home. If your compliance posture gets easier to defend when data never leaves your network, that is the argument.

Search: keyword vs SQL

Papertrail searches by keyword and phrase, with saved searches and alerts on top. It is fast and anyone can learn it in a minute.

Central Logging stores logs in SQLite and gives you full-text search and real SQL. SQL changes which questions you can ask, because you get aggregation:

SELECT
    json_extract(msg, '$.request_uri') AS uri,
    COUNT(*)                           AS hits,
    ROUND(AVG(json_extract(msg, '$.request_time')), 3) AS avg_seconds
FROM logs
WHERE json_valid(msg)
GROUP BY uri
HAVING hits > 10
ORDER BY avg_seconds DESC
LIMIT 25;

“Show me my slowest endpoints by average response time” is a GROUP BY, not a text search. When your logs are JSON, json_extract reaches individual fields.

The counterpoint is fair. Keyword search has a much lower floor. Everyone on your team can already use it, and plenty of people do not want to write SQL. Central Logging ships both modes for that reason.

Migrating from Papertrail

If you ship to Papertrail today, you use syslog forwarding or remote_syslog2. Both translate directly.

Forwarding via rsyslog? You are changing one output action. The rsyslog guide covers it — the omhttp module posts to the ingest endpoint with disk-backed queueing.

Running the Papertrail agent on Linux? The CL Agent replaces it and ships systemd journal entries upstream. Install it, point it at your instance, done:

sudo ./clagent -install
sudo systemctl enable --now clagent

Applications POSTing logs directly? The ingest API takes plain text, JSON, batches, and gzip:

curl -X POST https://logs.example.com/api/v1/ingest_logs/YOUR-SOURCE-TOKEN \
    --data-binary @mylogs.txt

Run both in parallel for a week before you cancel anything. Log shipping looks correct right up to the first time you need it.

What you also get

Papertrail is a log tool. Central Logging bundles the monitoring that small teams end up buying separately:

• Cron monitoring — heartbeat checks that alert when a scheduled job fails or quietly stops running.
• Website monitoring — uptime, response time, TLS expiry, and keyword checks every minute.
• Host monitoring — server health and check-in alerts.
• Metrics — scrape Prometheus endpoints and chart counters and gauges.
• Alerting — SQL or FTS alert rules to Slack or Telegram, with throttling.

Paying for Papertrail plus a cron monitor plus an uptime checker? This replaces three subscriptions.

When Papertrail is the better choice

Straight answers beat a sales pitch:

• You do not want to run a server. This is the big one. Central Logging is low-maintenance, but low is not zero. You own the uptime, the backups, and the disk.
• You log a lot. Central Logging targets teams under about 10GB/day. Past that, use something built for scale.
• You need someone to call. SaaS comes with an SLA and a support org.
• Your team will not write SQL and keyword search covers you. Then the main technical advantage does not apply.
• You need multi-region redundancy out of the box. One binary on one server is one point of failure. Backups and a standby mitigate it, and that is work you are signing up for.

When Central Logging is the better choice

• You already run at least one server.
• Your logging bill has grown faster than your traffic.
• You have thought about logging less to save money.
• Log data leaving your infrastructure is a compliance problem.
• You want aggregate queries over logs, not just search.
• You are also paying for cron and uptime monitoring separately.

Try it

The free download is the whole product, not a trial. No credit card, no time limit.

Install it. Ship one day of real logs at it. Run the queries you run every week and see whether they feel better or worse than what you have now.

Buy it, dislike it, and you get a 14-day refund with no questions.

See Deploy to get started.