The front desk calls: Altru won’t load, or it loads and then throws “Service Unavailable,” or a cashier gets a database error halfway through a sale. The line is already forming. What you do in the next ten minutes matters more than figuring out the cause, because the cause is usually something you can’t fix yourself.
Altru is hosted by Blackbaud. When the application or its database has a problem, the repair happens on their side. Your job is to confirm what kind of problem it is, keep selling and admitting guests safely, and leave a clean trail so you can put everything back into Altru afterward.
First, figure out whose problem it is
Spend two or three minutes on this before you call anyone. It changes what you tell staff.
- Is it one computer or everyone? Try Altru from a second workstation and from a phone on cellular data. If it works on the phone but not at the desk, the issue is probably your network, firewall, or that browser.
- Can the desk reach other websites? If nothing loads, call your IT person or internet provider, not Blackbaud.
- Check Blackbaud’s system status page. Blackbaud publishes service status for its hosted products. If an Altru incident is posted, you know it’s on their end, and you can stop troubleshooting locally.
- Note the exact error text and time. “Service Unavailable,” a timeout, a login loop, and a database error mentioning a full transaction log point to different things. Support will ask, and a screenshot saves a round of back-and-forth.
About the “transaction log is full” error
This one alarms people because it sounds like you did something wrong. You didn’t. The transaction log is part of the database behind Altru, and because Altru is hosted, managing it is Blackbaud’s job, not something your staff can reach. A full log usually means the database can’t record new changes, so saves fail across the board while some screens may still open.
There’s nothing to clear or reset from your side. Open a support case right away, include the full error message, and say clearly that you’re unable to process transactions. If you’re unsure whether something a user ran (a very large import or batch, for example) could have contributed, mention it so support has the context, but don’t try to re-run it until they confirm the system is healthy.
Keep the doors open while you wait
You won’t know up front how long an outage will last, so plan as if this one could run all day. Decide on a few things ahead of time so the desk isn’t improvising:
- How you’ll take payment. Altru-integrated card processing won’t work while Altru is down. Know whether you have a standalone card terminal or another way to take cards, and whether you’re willing to accept cash only for a while. Don’t write down full card numbers on paper as a workaround; that creates a security problem much bigger than the outage.
- A paper sales log. One line per sale: time, item (admission type, membership level, donation), quantity, amount, payment method, and the guest’s name and email when they’re willing to give it. Number the sheets so none go missing.
- How you’ll admit people who already bought. Online tickets and member cards can’t be looked up live. Decide whether staff will accept a confirmation email or card on sight, and log the names so you can check them later.
- A recent member list. If you regularly export an active-members query to a spreadsheet, staff can check status without Altru. If you don’t, this is the strongest reason to start: refresh it weekly and keep a copy somewhere that doesn’t depend on Altru being up.
- What to tell guests. A one-line script (“our ticketing system is down, we’re processing sales by hand, thank you for your patience”) keeps staff from over-explaining.
Also tell the people who aren’t at the desk. Development and membership staff entering gifts, running batches, or importing records mid-outage can end up with half-saved work. Ask everyone to stop and wait for the all-clear.
Working with Blackbaud support
When you open a case, give them what speeds things up: your organization name, the time the problem started, how many users are affected, the exact error text, and whether this is blocking sales. If a status incident is already posted, reference it and ask to be notified when it’s resolved. Keep the case number on the paper log so the shift lead can follow up without starting over.
After Altru comes back
The outage ends; the reconciliation is where mistakes creep in. Before anyone starts entering backlog:
- Check for partial transactions. Look at sales and gifts entered right around the time the problem started. A save that errored may or may not have gone through. Confirm before re-entering, or you’ll double-count revenue.
- Assign the backlog to one or two people. Entering paper sales into daily sales is easier to audit when the same person does all of it and initials each line as it’s entered.
- Use the right date. Decide whether hand sales should carry the actual sale date or the entry date, and follow your finance team’s rule so revenue lands in the right period. If you aren’t sure how Altru handles back-dated entries for your setup, test one in a sandbox or ask support before entering the whole stack.
- Match totals to the money. Paper log totals should agree with cash counted and the standalone terminal’s settlement report. Fix differences before the batch is committed, not a week later.
- Follow up on unverified admissions. Check the names you admitted on trust against Altru. Most will be fine; the few that aren’t are worth a polite email rather than a confrontation at the next visit.
- Re-run anything that was interrupted. Imports, batches, and scheduled processes that failed mid-run should be checked for partial results before you start them again.
Write the downtime plan before you need it
A one-page plan taped inside the desk drawer does most of the work: who to call, where the status page is, where the paper log and member list live, how to take payment, and who reconciles afterward. Do a five-minute walkthrough with seasonal staff at the start of each season. When the next outage comes, it’ll be an inconvenience instead of a scramble.
Quick answers
Can we fix a full transaction log ourselves?
No. The database is hosted and maintained by Blackbaud. Open a support case with the exact error.
Should we keep retrying a sale that errored?
Not repeatedly. Note it on the paper log, then check after recovery whether the first attempt saved, so the guest isn’t charged or recorded twice.
