When a Canary trend stops updating, the data has usually not been lost: it is waiting in a buffer between the collector and the Historian. Canary's Store and Forward service, and the Sender and Receiver services it replaced, show where the data is waiting and why. This article explains how to read those services and the common faults Canary documents, from the Canary Community knowledge base for versions 25 and 26: what changed in version 24, the Store and Forward tile, ports and certificates, the licensed tag limit, and dataset and tag name problems. How the Canary System is built: Canary Historian architecture.
1. Store and Forward since version 24
From version 24, every Canary collector sends data through the Store and Forward service, which combined the older Sender and Receiver services into one. A Store and Forward service sits next to each collector and next to the Historian, sends and receives data, and buffers it to disk when it cannot reach the next service. The connection is started from the sending side, and the receiving side listens on gRPC port 55291, with data in transit encrypted by TLS. The Historian still accepts data from Sender and Receiver services used by collectors older than version 24, and Canary's documentation states that the Sender service will be discontinued in version 27.
2. Reading the Store and Forward tile
The tile in Canary Admin shows the number of streams, the buffer, the input and output rates per second, and the number of local and remote tags. A buffer builds whenever input per second exceeds output per second. The Status screen lists every session with, among others:
| Column | What it tells |
|---|---|
| Hops | the chain of servers the session has passed, for example A to B to C |
| Destination | localhost when the data is stored in the local Historian, otherwise the next Store and Forward service |
| Output State | Open when sending, Closed when disconnected, Hold when waiting for another session, Throttled when the destination returns a bad status that usually needs user action |
| Buffer Count | values waiting to be sent |
| Queue Order | how many earlier sessions must finish before this one sends |
The tile also offers Pause and Purge. Purge deletes a session and its buffered data; Canary keeps a backup of purged sessions under C:\ProgramData\Canary\StoreAndForward\Purged by default.
3. Settings that decide how long data can wait
| Setting | Effect given by Canary |
|---|---|
| Buffer Disk Space Limit (MB) | data is buffered until only this much disk space is left, after which no more data is buffered |
| Buffer Backup (days) | keeps buffer files in a backup folder for the set number of days after they are sent; by default they are deleted at once |
| Buffer File Rollover Size (MB) | starts a new buffer file at this size |
| Lazy Buffer | writes straight to the destination and falls back to the buffer if that fails or a buffer already exists |
Canary recommends turning on Buffer Backup where data is highly sensitive, to keep a window of recovery if data is lost at the destination.
4. Common faults in Canary's troubleshooting guide
| Symptom | Cause given by Canary | What Canary suggests |
|---|---|---|
| A service does not start | two certificates with the same subject name, logged as a duplicate certificate error | remove one of the duplicate certificates from the computer's personal certificate store |
| The sending side cannot connect, and the buffer grows | receiving services stopped, wrong Historian or proxy name in the collector, or a firewall | check the services, check the server name (the first branch of the session name), and allow the port through the firewall |
| All data from all sources buffers | the Historian's licensed tag limit is exceeded | check the License and Historian tiles, remove tags or a dormant dataset, or obsolete tags and roll the dataset over |
| An anonymous connection works, a secure one does not | the sending service is on the deny list of the receiver | allow its identity in the receiver configuration and check the secure port in the firewall |
| Tag names are red in the OPC DA Logger | the dataset does not exist or its name does not match; names are case-sensitive | create the dataset before logging, or correct the name |
| A blocking error: the tag is already logged | the same tag logged twice, one copy with a trailing space that the Historian trims | remove one of the tags; Canary recommends contacting its support to flush the buffer |
For the older Sender and Receiver services, the default ports are 55255 for an anonymous connection and 55256 for a secure one.
What we check first
These are TDL's working habits, not Canary requirements:
- The buffer count and output state of each session, before restarting any service, so that buffered data is not purged by mistake.
- The licensed tag count against the tags actually logged, after any new collector or tag import.
- Free disk on each collector computer against the Buffer Disk Space Limit.
- Firewall rules for port 55291 between each level of the network.
How TDL approaches it
TDL Industrial Automation is a Canary Certified Partner, listed on Canary's partner page for Vietnam. Our historian work so far has been on Rockwell Automation platforms, for example FactoryTalk View SE with FactoryTalk Historian at the Vinh Hoan FeedOne aquafeed plant. On a Canary system we start from the collector side, because that is where the data waits during an outage. More on this service: Canary Historian in Vietnam.
Frequently asked questions
Why has a Canary trend stopped updating?
Often because the data is buffering in the Store and Forward service on the collector side. The Buffer Count and Output State on the Store and Forward tile show where it is waiting.
Does purging a Store and Forward session lose data?
It deletes the session and its buffered data. Canary keeps a backup of purged sessions under C:\ProgramData\Canary\StoreAndForward\Purged by default.
Why is data from every source buffering at once?
One cause in Canary's guide is that the Historian's licensed tag limit has been exceeded; data from all sources then buffers until the tag count is within the limit.
Which port does Store and Forward use between servers?
The receiving Store and Forward service listens on gRPC port 55291, with data encrypted by TLS.
Sources
- Canary Labs, Sender/Receiver Troubleshooting Guide (version 26), Canary Community knowledge base
- Canary Labs, Store and Forward Tile (version 25)
- Canary Labs, Sender Tile (version 26)
- Canary Labs, Canary Partners
Read 13 November 2026. This article paraphrases the sources and does not quote them; read the original documents before designing or working on a system.