If your cloud school software will not open, first check whether the fault is local — internet, browser, device or an expired session — by testing a second device on mobile data; if two independent paths fail the same way, report it to support with the time, screen, screenshot and number of users affected, and keep collecting on printed challans meanwhile.
How do you tell a local problem from a platform problem?
Most "the system is down" calls from a school office turn out to be one desk, one browser or one internet link. Spend two minutes on triage before you escalate, because the answer changes who has to fix it.
The test is simple: try to reach the portal from a completely different path. A second computer on the same office Wi-Fi is not a different path; a staff member's phone on mobile data is.
- Open the portal on a phone using mobile data, not the school Wi-Fi. If it loads, the fault is your office network.
- Ask a colleague at another campus to try. If they are fine, the problem is local to your site.
- Check whether the Android apps (Parents, Teachers, Owners) still work. Apps failing at the same time as the web portal points to something wider than your browser.
- Sign in again from scratch. Sessions expire, and an expired session can look like a broken screen rather than a logout.
- Confirm the login inputs: staff sign in with the school's institute code, a username and password; parents log in with a one-time code sent to the registered mobile. A wrong institute code will never let anyone in.
- Try a different browser or a private window, and confirm the address starts with https://.
What should the office keep running while the portal is unavailable?
Schools do not stop because software does. Decide in advance, not on the morning it happens, what the front desk and fee counter will do for an hour or two without the portal.
A short manual fallback keeps the day moving and, more importantly, keeps the data recoverable afterwards. Anything written on paper during the outage must be entered afterwards, so write it in a form that maps to the screens you normally use.
- Fee counter: accept payment against the printed challan the parent is carrying, note the challan number, amount, date and receiver, and post it in the portal once access returns.
- Attendance: take the class register on paper; marks can be updated later, and corrections to a past day are logged.
- Front desk: keep a manual visitor and exit-pass register with times, and transfer the entries afterwards.
- Parent communication: if you must inform families, use the school's own SIM or WhatsApp number directly rather than waiting for the queue.
- Tell staff one agreed message. Uncoordinated "the system is finished" messages to parents create more work than the outage itself.
How should admin staff report the fault so it is fixed quickly?
Support engineers can only act on specifics. "It is not working" starts a conversation; a precise report starts a fix.
Send everything in one message rather than in five. For EDUBase schools, support is available by WhatsApp group, phone and in-app requests from 9:00 AM to 5:00 PM on working days, while the AI assistant, tutorial videos and documentation are available round the clock for how-to questions.
- The exact time the problem started, with the date.
- The screen or module you were on, and what you clicked just before it failed.
- A screenshot of the error, including the browser address bar.
- Your institute code and the username affected (never the password).
- How many users are affected: one desk, one campus, or everyone.
- What you already tried: second device, mobile data, re-login, different browser.
- Whether the Android apps are affected too.
What happens on the platform side during an incident?
On a managed cloud platform, the school is not expected to run servers or watch dashboards. EDUBase Cloud is hosted and maintained by the EDUBase team, with external monitoring of the servers, the resolver and the messaging gateway, and alerting when a check fails.
Two design choices matter during any incident. Each school's data lives in its own database, so a problem in one school's data does not reach another school's records. And regular database backups are kept off the application servers, so the restore path does not depend on the same machine that is having the problem.
All portal, app and integration traffic runs over HTTPS, and attendance tablets, sender phones and gates hold their own revocable device credentials, so a lost or misbehaving device can be cut off without changing anyone's password.
What should you check once the software is back?
Do not assume the day repaired itself. Spend fifteen minutes reconciling before the office closes, while people still remember what happened.
The reports you already use are the fastest way to verify: Day Wise Paid Challans for the cash-up, Payment History for bank-posted payments, and the attendance reports for any class marked on paper. The User Logging page shows who created, changed or deleted what, with severity and a link that opens the record with the change highlighted, which settles most "was this entered twice?" arguments.
- Post every manual receipt taken during the outage and match the total against the day's cash.
- Confirm bank-collected payments have posted; a challan already paid answers as paid to any later inquiry, so a family cannot be charged twice.
- Enter the paper attendance and let absentee alerts go out, or decide deliberately not to send them late.
- Check that scheduled runs you expected — challan generation, late fees, defaulter reminders — actually ran; each automation keeps a run history showing what it did.
- Review the activity log for anything entered twice during the confusion.
How do you reduce the impact of the next outage?
Outages are rare events with predictable consequences, so the useful work is done beforehand. Write a one-page continuity note and put it on the fee counter and the front desk.
Reduce single points of failure at your own site first, because that is where most "downtime" originates: one internet link, one browser profile, one person who knows the login.
- Keep a backup internet option (a mobile hotspot) for the fee counter and front desk.
- Make sure more than one authorised person can access each critical screen, using per-user, per-screen privileges rather than a shared login.
- Print the current month's challans in advance where your policy allows, so the counter can still collect.
- Keep the support WhatsApp group, phone number and institute code written somewhere the office can find them without logging in.
- Export key reports to Excel periodically if your finance officer wants an offline copy for reference.
- Agree in advance who speaks to parents during an incident, and in what words.
Common "system is down" symptoms, likely causes and who resolves them
| Symptom | Most likely cause | What admin staff should check | Who resolves it |
|---|---|---|---|
| Portal does not load on one PC only | Local network, browser cache or device fault | Try mobile data on a phone; try another browser or private window | School IT / office staff |
| Nobody at one campus can log in | Site internet link or local firewall | Test the same login from mobile data outside the building | School IT / internet provider |
| Login rejected with correct password | Wrong institute code, or the session expired | Re-enter school code plus username; ask an admin to reset the password | School admin user |
| Parent cannot log in to the Parents App | One-time code not received on the registered mobile | Use the Parent App OTP Portal to look up or issue the code; confirm the mobile number on the student record | School office |
| Portal and all Android apps fail everywhere | Platform-level issue | Confirm with a second campus and mobile data, then report with time, screen and screenshot | Vendor support and hosting team |
| Messages not reaching parents | SMS device, gateway or WhatsApp link, not the portal | Check SMS Report, App Notification Report and WhatsApp balance and history | School office, escalate to support if settings look correct |
| A scheduled fee run did not happen | Automation switched off, scope or schedule setting | Open the automation's run history to see what it did and when | School finance user, escalate if the history shows a failure |
Related
- Cloud & Infrastructure Services — Managed hosting, one database per school, backups, monitoring and secure networking for education workloads.
- Training & Support — Live Google Meet training, module video playlists, in-app docs and an AI assistant, with WhatsApp and phone support in working hours.
- Integrations: Bank, SMS, WhatsApp & Biometric — Bank fee collection with HBL, Bank Alfalah, Meezan, PayPro and KuickPay; SMS and WhatsApp gateways; QR, biometric and face devices.
- Hosting security on edubaseems.com
- Users privileges security on edubaseems.com
- Parents app controls on edubaseems.com
- Fee reports on edubaseems.com
- Ai assistant on edubaseems.com
- Sms whatsapp notifications on edubaseems.com