Database connector

The database connector mirrors your Routy data into your own database: clicks, conversions and page views land in tables you own, so you can query them with your own tools alongside everything else you hold.

This screen is where you point us at that database, pause the writing, and check what we have actually written. The figures on it are the subject of most of this page, because a row count on its own cannot tell you whether the mirror is keeping up.

Connection

The card at the top shows the engine, the host and port, the database, the schema and the user we connect as, and a badge for the connector's state.

• Test connection opens a connection from our network to yours, right now, and tells you what happened. Use it after any change at your end: a rotated password, a new firewall rule, a moved host.
• Pause stops us writing without deleting anything. The connector keeps its settings and its history, and Resume starts the writing again. Data that arrives while you are paused is not held for you — pause is not a buffer.
• Edit changes the connection details. Delete removes the connector from Routy; it never touches the tables in your database.

If the connector is in an error state, the reason we were given is shown under the connection details. That text comes from your database, not from us, so it is usually the fastest clue: an authentication failure, a missing schema, a refused connection.

Delivery health

Four figures, covering the period in the selector at the top right.

A healthy period reads attempted = saved + duplicates skipped. Anything left over after those two is loss, and it is counted under Dropped.

The save rate is why these figures exist. "3 clicks saved in the last hour" reads identically whether we were handed 3 rows and saved all of them or handed 4,000 and saved 3 — and only the second is a problem. The rate answers that, and nothing else on the screen can.

Duplicates are not failures

We deliver at least once. That is deliberate: it means a row can arrive twice, and it means a row never silently fails to arrive because a delivery was retried. When a row we send is one your database already holds, the insert discards it and it counts as a duplicate skipped.

So a high duplicates figure is not data loss and is not something to report. It is at-least-once delivery working as designed, and it is at its highest right after a reload or a catch-up, when we deliberately re-send a window of data.

A dash instead of a save rate

The save rate shows a dash — not 0% — whenever the period has nothing to divide by:

• Nothing was written, because nothing happened. A quiet night on a low-volume account reads "nothing to write", which is not a failure.
• The period is older than the counters. We only started counting attempted rows recently, so any hour before then has rows saved and no attempted figure to compare them with. There is no save rate to show for those hours, and the dashed line on the chart breaks rather than dropping to zero.

Both cases are the same answer: we cannot tell you, for this period. They are not 0%, and you should not read them as one.

Conversions have no save rate

Conversions are written one at a time rather than in batches, so there is no batch of attempted conversions to compare against. Conversions is still reported as a count; it is deliberately left out of the save rate.

Similarly, Duplicates skipped and Dropped cover clicks, conversions and page views together. They cannot be attributed to one of the three, which is why they are shown as their own figures rather than subtracted from a row count.

Data ingestion over time

One point per hour across the selected period: clicks, conversions and page views saved, with the save rate as a dashed line on the right-hand axis.

Hovering an hour gives you all of it at once — what was saved, what was attempted, how many duplicates were skipped and how many rows were dropped — so you can check attempted = saved + duplicates skipped on the hour that looks wrong.

Two things to keep in mind when reading an individual hour:

• The figures are per hour, not running totals. On a very low-volume connector — a handful of rows a day — an hour reading 0 means nothing happened in that hour. Read a day in aggregate before concluding anything.
• An empty chart means we have nothing to show for the period, which is not the same as a broken connection. Check the state badge and Test connection before assuming the worst.

Errors, dropped and duration

The second chart separates the two kinds of bad news, because they are acted on differently:

• Dropped (red) is rows that did not get written. If this is above zero and stays there, data is missing from your database and the gap will not close on its own.
• Errors (amber) is operations that failed. A retry often succeeds, so a few errors with a save rate still near 100% is noise rather than a problem.
• Average duration is how long our writes took, on the right-hand axis. A climbing duration is usually the first sign that the database is under load, often before anything starts failing.

When something looks wrong

The save rate is well below 100% and duplicates do not cover the gap. Rows are being lost. Check the state badge and the error message, run Test connection, and look at whether the duration chart climbed at the same time — a database that got slow is a different problem from one that refused a write.

Dropped is above zero. Note the hours it happened in; that window is the one to compare against your own database logs.

Everything is zero and the connector is enabled. Nothing was handed to us to write in that period. Widen the period before investigating the connector.

The save rate is a dash for every hour. Either nothing was attempted, or the period predates the counters. Pick a recent period — the last 24 hours — and check again.

If rows are still missing after all of that, contact support with the connector engine, the hours involved and what the delivery figures read for them.